- From: Paul Prescod <paulp@ActiveState.com>
- Date: Mon, 27 Aug 2001 14:57:40 -0700
- 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