RE: Proposed issue; Visibility of Web services

+1.

And imagine when we want to deal with sending complex queries.  There's
simply to much software that barfs on long URI strings.

Besides, there's this XML thing that allows extensibility and it has this
query language, I think it's hot.  What the "resource" is when a complex
query across a complicated data model is sent to an origin server often
seems unclear to me.  Spare me the bank account example, it's the big old DB
with lots of tables with complex join queries that I'm talking about moving
around.

I would have thought that more folks would come up with XQuery to URI
binding.  Most people forget that the "?ticker=IBM" syntax is actual HTML
form encoding too..  That one always cracks me up, that many of the *** to
URI mappings use the HTML form encoding, and that's somehow supposed to be
expressive enough for all the queries we want.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of
> Christopher B Ferris
> Sent: Friday, May 30, 2003 5:44 PM
> To: www-ws@w3.org
> Subject: 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 21:23:23 UTC