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