Re: Proposed issue; Visibility of Web services

Alan Doyle wrote on 05/30/2003 05:20:23 PM:

> 
> My understanding of REST is that anything after the GET that requires 
"out of
> band" knowledge about the resource you're sending the GET to reduces
> the visibility.
> 
> For example, if I build a stock quote service that takes requests of
> the form
> 
>   http://my-service.com/quote.cgi?ticker=IBM
> 
> it's more opaque than a similar service where the form is
> 
>   http://my-service.com/quote/IBM

I don't understand why you are suggesting that the former is more opaque 
than
the latter. 

> 
> In order to be properly RESTful, the latter should appear as a link
> in some other document so that it can be reached via a transition
> from a previous representation.

You can us query parameters for this as well. A URI is a URI. It is
just as valid to return a URI of the first form in a document as it is
to return one of the second form.

> 
> If you look at some of Paul Prescod's writing about UDDI, for
> example, he describes this quite nicely.
> 
>  http://webservices.xml.com/pub/a/ws/2002/02/06/rest.html
>  http://www.google.com/search?q=prescod+uddi

Hey, look! The second article takes a query parameter and yet is being 
used
in an equally RESTful manner as the first link to one of Paul's articles:)

> 
> Getting back to the example at hand, it's not the fact that SOAP was
> used to encode the query that made it opaque. It's the fact that the
> query had to be so complex at all.

Oh? Are you suggesting that there is no value in complex queries? Or, are 
you
suggesting that SOAP itself is an overcomplication of something that could
easily be quite trivial and simple? For the trivial case such as 
getStockQuote,
I might agree, but life is rarely that simple.

I could easily hide an extraordinarily complex query, one that involved 
complex
table joins from different databases, transforms and all manner of 
gonculation
behind a very simple URI such as:
        http://example.org/a/really/complex/query

Of course, that means that the arguments to the query must be fixed
and assigned to the URI, which might be fine if the query were not
something that indeed took different arguments.

I suppose that would be okay if I spent all of my waking hours defining 
all possible
permutations of the really complex query and assigning each possible
query a unique URI. Or, I could be really lazy (as I am!) and simply 
provide a means of encoding the possible query arguments into the URI.

Whether the URI is created by the origin server or by the client is not 
important.

> 
>       Allan

<snip/>

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

Received on Friday, 30 May 2003 20:44:38 UTC