

Re: FW: LC Comments: Web Method Feature (really: REST & SOAP)

From: Paul Prescod <paul@prescod.net>
Date: Mon, 08 Jul 2002 10:34:43 -0700
Message-ID: <3D29CD33.DBAADD9D@prescod.net>
To: Eugene Kuznetsov <eugene@datapower.com>
CC: "'Champion, Mike'" <Mike.Champion@SoftwareAG-USA.com>, xml-dist-app@w3.org

Eugene Kuznetsov wrote:
> ...
> I think one difference is that XML & XHTML can be part of the
> same world, consumed by the same clients. The whole point of
> HTML, content-negotiation and browsers gracefully falling back
> to LCD is that the consumers are the same -- so the nature of
> layering is important. To use the <P> example, you could have
> something like <P author="john"> and <P author="joe">, and all
> browsers could still make sense of it -- and some could take
> advantage of the "author" attribute. This kind of extensibility
> is important.

This kind of extensibility is known in the Web architecture as "Partial

 e.g. "http://www.wired.com/news/technology/0,1282,11693,00.html

Partial understanding is a core component of all interoperable software
development. Very seldom do components know the full scope of their
environments. Rather they know just enough to get their jobs done.

> However, the target for HTTP-transported web services isn't
> the same as HTML browsers. It's a bit like streaming video
> -- OK, yes, you can transport it over HTTP, but it requires
> totally different functionality and there's no graceful
> 'fallback' for an HTML-only browser -- but even more so, where

All good, interoperable, extensible network software is designed to work
with partial understanding. Your mail client probably does not
understand every header in the current message. It understands enough to
do its job. Other intermediaries understand other bits. 

If you do not tunnel, you allow HTTP-knowledgable software components to
do their job:

 * Squid can cache based on URIs, method names and cache headers
 * Spiders can walk through the resource graph looking for information
relevant to them
 * Service containers can implement recursive deletes of resource
hierarchies (with WebDAV)
 * Load balancers can do balancing based on URIs
 * Resources can be retrieved for basic processing with "wget" and
replaced with "curl"
 * Internet Explorer can graphically display resource representations
(probably using <?xml-stylesheet ...?>)
 * Windows Explorer can graphically allow the browsing, moving,
deleting, etc. of resources
 * Any resource may refer to any resource, anywhere in the universe
using only URIs
 * You can use Apache to help dispatch messages to the appropriate
 * Apache can do "redirects" when resources are moved or merged
 * Any resource may incorporate information from any other resource by
reference using XPointer, XLink, etc.
 * Any resource may be annotated with metadata either through WebDAV or
RDF or both.

Okay, Squid does not know that the GET means "GET purchase order" but it
knows how to cache gets. Windows Explorer does not know that "DELETE" of
a travel itinerary means "cancel trip" but it knows how to delete (it
doesn't REALLY know what it is deleting even in the local case). Your
RDF engine does not know why you are adding metadata or what the
annotations mean. Your XSLT engine doesn't know that following a link
fetches a user's address. 

But they doesn't need to know everything. Neither does your SQL engine
understand that an UPDATE to the "purchase orders" table means add a
purchase order. It just knows the semantics of the SQL specification as
Apache knows the semantics of the HTTP specification. Your application
layer semantics can be expressed *in the data*, not the operation names.

> at least with HTML & video you still have a person consuming
> the data, but with web services it's a server-to-server comlink.

I think that we can do much better than a "comlink". Interoperability
requires a more globally shared understanding of the universe. Web
architecture provides that. If you think of the universe as being
composed of addressable, mutable, active resources, you can get much
more interoperability than if you think of the universe being composed
of nodes that only know how to "SEND" and "RECEIVE" (which is basically
the "message-oriented" view that people are so anxious to tunnel on top
of HTTP).

We are in a big hurry to give up the high level of practical, workable
interoperability possible with tools that exist today in favour of the
shibboleth of protocol independence.
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
Received on Monday, 8 July 2002 13:35:24 GMT
