All,

Sorry that I've taken so long to reply to this thread.

Going back to the beginning, I concur with Dave that the issue of GET/POST in Web services has nothing to do with safe and unsafe.

In reference to Paul comments (see below), it's not true that "every bit of information on the Web should have a URI address". There's lots of discrete information on any random Web page that doesn't have a unique URI. It is true that every Web *resource* has a URI. I view a Web service as a Web resource, and hence every Web service should have a URI. (I think we've made this association in our Web service definition statement.) If you attempt to perform a GET on most Web service URIs, you usually get a WSDL description back. Doesn't this qualify as "a clear statement of how to dereference addresses to retrieve information"? I believe that SOAP supports both of the requirements that Paul stated to qualify as a Web protocol.

In reference to Mike and Nigel's comments regarding SOAP caching, I have to side with Don Box. I'd much rather buy a new SOAP-aware Web services router/cacher than force my users to express sensitive application information in a URL. (What if I need to encrypt the data that I'm sending to the service?) See also Mark Nottingham's comments on the viability of Web service caching based on REST. More to the point -- how do I specify a purchase order (which is a pretty common example of a SOAP input message) in a URL? If you view SOAP as only an RPC, then you're ignoring a significant use of SOAP.

Some may view the mis-use of POST as morally wrong, but as a group representing its members, W3C needs to accomodate the wishes of its members. Mark Baker is way off base when he said that RPC "has repeatedly demonstrated its inability to be deployed on the Internet". SOAP RPC is being used quite successfully right now. My customers could care less whether SOAP over HTTP POST is conforment with what some are now trying to define as "the Web architecture". They just want something that works, and SOAP over HTTP POST works.

If W3C follows a path that defines the "Web architecture" as being equal to the REST architecture, it will force the W3C working groups to abandon use of SOAP over HTTP POST. This will cause an unacceptable delay in the standardization of SOAP. Next we'll find that very few vendors will adopt the new standards, and customers will be very happy to use products based on SOAP 1.1 and WSDL 1.1. This path will lead W3C into obscurity, and WS-I will become the de facto Web services standardization group.

It's not that I don't think REST is interesting, it's just that the REST architecture and the current Web Services architecture (based on SOAP 1.1) are fundamentally different, and we can't attempt to force such a significant change on technology that's being successfully used today.

I think it's a great idea to develop a new model for Web services based on the REST architecture (although we may want to call them REST services or something else). Just don't let REST interfere with the release of SOAP 1.2 and WSDL v.next.

Respectfully,