W3C home > Mailing lists > Public > xml-dist-app@w3.org > August 2001

Re: SOAP and the Web architecture

From: Paul Prescod <paulp@ActiveState.com>
Date: Mon, 27 Aug 2001 14:57:40 -0700
Message-ID: <3B8AC254.725BB31E@ActiveState.com>
To: xml-dist-app@w3.org
Eugene Kuznetsov wrote:
> I must still be missing something about POST & GET in this context
> -- how does it make a difference from the application's point of view?
> When it is a browser, I can see how saving the parameters with a URL
> might be useful. When it is an HTTP proxy of some kind, I understand
> the differences, and certainly there are some stickiness and caching
> implications. But for a web service? I'm sure there is something I'm
> missing.

First, I'm not sure that there is or should be a real distinction
between web services and web applications. Traditionally, web
applications return HTML. Maybe a web service is just an web application
that returns XML. You can access it from a web page or from a
programming language. You can stuff the results into a database or
render it with XSLT. Otherwise, no difference. This is just an idea I'm
playing with....the Web architecture is proven to work and to scale so
I'm curious when I hear the REST guys saying that the same architecture
works for web services. It makes intuitive sense to me.

There is all of this infrastructure for the-Web-as-we-know-it that is
not going away. Caches, proxies, firewalls, browsers, annotators,
loggers, "rankers", hyperlinkers, visualizers, transformation engines
and almost all of that stuff can be logically applied to stock quotes.
Or state names. Or temperature conversions. It's just a matter of
plugging in the URL.

I have a variety of XSLT stylesheets that I use to extract information
from Google and many command line scripts for extracting things from
other websites (basically lynx -dump | grep). All of this is going to
get more complicated in a post-GET world. 

More important: if I want to compose multiple XML services into a single
virtual service I can do it either by setting up a proxy or by making
references. e.g. in my purchase order service I will want messages to
make hyperlinks to the product catalog service and maybe currency
conversion services. Part of the promise of XML is a highly connected
web (whether "semantic" or otherwise).

Using standard XML techniques I can refer not just to another XML
document but even to a single element or character in an XML document.
But I can't do that if the thing I want to refer to doesn't have a
URL...and I haven't yet seen a proposal for the SOAP URL syntax (though
maybe I missed that).

It doesn't make sense to make hyperlinks to the results of all web
services method calls. That's why URL-based calling needs to be an
option, not a requirement.
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook
Received on Monday, 27 August 2001 17:58:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:15 UTC