RE: FW: draft findings on Unsafe Methods (whenToUseGet-7)

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:50 UTC