- From: Hutchison, Nigel <Nigel.Hutchison@softwareag.com>
- Date: Tue, 16 Apr 2002 18:44:04 +0200
- To: "'jones@research.att.com'" <jones@research.att.com>, moore@cs.utk.edu, www-tag@w3.org
- Cc: dorchard@bea.com, www-ws-arch@w3.org, xml-dist-app@w3.org
In Software AG we have had, over the last couple of years, similar arguments about the use of HTTP in the REST way, as apposed to using in the way described in your typical quotation from the anonymous book. Of course it was not called REST by us, but something like "mumble mumble as it actually says in the HTTP 1.1 spec". Most of the developers made their first stumbling steps with HTTP using books and examples and got around to reading the HTTP spec quite a bit later. (me too) Some were quite amazed to find what the spec actually included. I was able to stop one bunch of guys adding new Software AG proprietary verbs to HTTP. Our experience suggests that persuading developers to read the spec and exploit the technology is not a hopeless task. My opinion at the time, and up to now, was and is, HTTP as specified and implemented in browsers and web intermediaries is a wonderful thing and has been proved to be useful and scaleable at the planetary level. Just hacking RPCs over HTTP on a "gee, that works basis" isn't exploiting the existing infrastructure. It is like using a chainsaw to cut down a tree without pulling the rope first. I personally find the prospect of having to buy a SOAP Cache from (name your Web Services technology supplier) to make a web service scaleable, instead of using existing web intermediary technology like Squid, somewhat distressing. Particularly if it could have been avoided by some concerted activity in the W3C. regards Nigel Hutchison Nigel W.O Hutchison Chief Scientist, W3C AC Representative Software AG Uhlandstr 12, D-64297 Darmstadt, Germany Tel +49 6151 92 1207 > -----Original Message----- > From: jones@research.att.com [mailto:jones@research.att.com] > Sent: Tuesday, April 16, 2002 5:45 PM > To: moore@cs.utk.edu; www-tag@w3.org > Cc: dorchard@bea.com; www-ws-arch@w3.org; xml-dist-app@w3.org > Subject: Re: FW: draft findings on Unsafe Methods (whenToUseGet-7) > > > Here's a quote from a random "web programming" book, which will > remain nameless: > > That's all the coverage we plan to give the GET method. In > fact, it's > not recommended for most serious CGI programming, because > it's limited > in the number of characters it can safely accommodate for transfer > between the browser and the host to an effective maximum of > 255 characters > (including the plus and equal signs used for URL encoding). That > may sound like a lot, but in a complex form, it's nowhere > near enough! > > In the sections that follow, we'll take a gander at the POST HTTP > method, preferred by most CGI programmers for serious data-passing, > because it is not subject to the limitations that restrict > GET's abilities to > transfer data from the browser to the server (and on to your > CGI programs). > > > With views like this having been very much in the ether for a long > time, it is hard to get the genie back in the bottle. Since there > are no guarantees anyway, I think a reasonable middle ground for > web services would be to have a standard vocabulary for services > to characterize their semantics along many dimensions, including > the strict GET/POST distinction. This would be useful across > bindings other than HTTP as well. > > Mark A. Jones > AT&T Labs > Shannon Laboratory > Room 2A-02 > 180 Park Ave. > Florham Park, NJ 07932-0971 > > email: jones@research.att.com > phone: (973) 360-8326 > fax: (973) 236-6453 >
Received on Tuesday, 16 April 2002 13:30:54 UTC