URIs and web services

> <DanCon>	"# Status of discussions with WSA WG about SOAP/WSDL/GET/Query strings?"
> <Norm>	TBray: we poked around and the WSDL issues list now contains an issue on this
> <Norm>	TBray: a month or six weeks ago they had an issue number you can point to but they hadn't actually done anything
> <Norm>	SW: can you dig out the issue number?
> <DanCon>	http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html
> <Norm>	DO (resurfaces): yes that was a fair summary
> <Norm>	Is this it: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html#x61
> <Norm>	No
> <Norm>	(No, it's not.)
> <Norm>	TBray: it's R085.
(from TAG IRC log)

I would like to point out that there are probably two related issues 
here and that may be the cause of some confusion. They both relate to 
how web services use URIs but only one has to do with GET/Query strings. 
I hope that this message will help some people to understand the difference.

The Web supports two means of navigation. The first is hypertext. The 
second is queries. Each has strengths and weaknesses. I'm going to quote 
from something I've written on the topic but feel free to skip it if you 
think you understand the difference:

====
>   = Hypermedia =
> 
> Often the
> client application or human web surfer will not know exactly what
> information they need in advance. Essentially they need to be given a
> menu of options so that they may choose the appropriate one. For
> instance a flight-purchasing agent might be presented with a list of
> flights and might choose the "best" one based on a complex algorithm
> that depends upon price, flight length and flight time. In this case, we
> need an information object (a flight list) that refers to other
> information objects (the flights). A data representation that has
> references embedded among data is known in Web terminology as "hypermedia".
> 
> Listing things is a wonderful way of helping a client navigate to
> information because they know exactly what is available and sometimes
> that knowledge as important as having access to any particular item.
> Google is an example of an application that really does not care about
> any particular page on your site much, but cares very much about
> ensuring that it has a relatively complete list of pages. So hypermedia
> is a very important part of web architecture because it allows
> discovery. Where possible, information delivered on the Web should be
> organized into webs of hyperlinked hypermedia documents.
> 
> Because the Web is basically a flat, global address space (modulo
> machines behind firewalls etc.), any resource can refer to any other
> resource, no matter whether they use the same data representation or
> even the same access protocol (e.g. HTTP versus FTP). This promiscuous
> connectedness is what makes the Web so great and important!
> 
> The great thing about using hypermedia as an organizational model for
> information repositories and services is that one process or individual
> can direct another process or individual to look at and deal with a
> particular resource by address and can choose the appropriate amount of
> context. For instance, you can direct a purchase order processing
> application to a particular purchase order rather than to a whole
> "purchase order application". This is in contrast to dominant web
> services methodologies that hide many resources behind a single URI and
> therefore makes addressing those individual resources impossible.
> Imagine if someone wanted to send you a link to the Wall Street Journal
> and required you to always go to the front screen!
> 
>   = Queries =
> 
> Sometimes the information provider has such a large database of
> information that it is not practically (or economically) feasible for it
> to deliver to the requestor in total or even to segment into many
> hypermedia documents. The requestor needs to specify some reasonable
> filter. This is a fallback position because it becomes difficult or
> impossible for the requestor to enumerate all of the information items
> even if this might be useful or important. Nevertheless, reality
> requires that sometimes filtering happen on the server side and the Web
> allows this through HTTP URI "query parameters".
> 
> The beautiful part of query parameters is that they are expressed as
> part of the URI so that all of the tools we've built up for downloading
> ordinary hyperdocument resources and lists of hyperdocument resources
> can also be used on filtered lists of hyperdocument resources. The only
> difference is that in this case, the URI is partially constructed by the
> client application, under instructions from the server, rather than
> being constructed by the server and being totally opaque to the server.
> But once the URI is constructed, it is as bonified a URI as any other
> one and may be put into any slot expecting a URI. They can be
> hyperlinked, cached, downloaded with command line tools,
> and so forth.

WSDL has incomplete but passable support for the latter mode of Web 
navigation but none whatsoever for the former kind of Web navigation. In 
object oriented terms, it must be possible for WSDL to describe 
pointer/reference relationships between services/resources. In my 
opinion, this is necessary if Web services are going to be _Web_ services.

For instance, almost everyone agrees that (for example) purchase orders 
should be first-class resources with their own URIs. (if you disagree, 
speak up now!) How will a WSDL communicate that a purchase order manager 
application has references to purchase order services/resources within 
it? Will methods that mutate and query into those resources be directed 
at the container "endpoint" (IMHO, illogical and confusion) or at the 
resources themselves (IMHO, more logical).

For the same reasons that it doesn't make sense to ask a 
"StockQuoteHolder" resource for a particular stock quote (versus asking 
the stock quote resources itself), it makes no sense to go to the 
StockQuoteHolder resource to UPDATE the stock quote or to do some 
sub-query on it.

Merely supporting the construction of GET query strings is not enough. 
It will lead to dual-personality services that use Web URIs and 
mechanisms for information retrievals and non-Web mechanisms for updates 
and sub-queries. Objects like purchase orders will tend to have two 
names, the one you use to mutate them and the one you use to retrieve a 
representation of them.

IMO, WSDL will not be complete if it does not allow me to declare a 
stock quote holder object which can be queried to return references to 
stock quote objects which can *themselves* be queried. And of course the 
link between the stock quote holder and the stock quote should be 
strongly type-declared. Even ignoring issues of REST and web 
architecture, it seems to me that it is a serious limitation if WSDL can 
only describe services with "global static methods" and none with 
methods that actually live on addressable objects.

IDLs have been able to handle this for years. The things that require 
new thought in the web services space is how to integrate properly with 
XML-described information and (orthogonally) with HTTP/REST.

Here are some relevant URIs:

  * http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0047
  * 
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html#x66
  * http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0106.html
  * http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0107.html
  * http://www.w3.org/TR/ws-desc-reqs (see requirement 85)

  Paul Prescod

Received on Wednesday, 11 September 2002 15:20:01 UTC