Anne Thomas Manes wrote:

We're getting off into a diversion. Can we agree that every piece of information available on the Web should be URL addressable or a PART of a URL-addressable resource? And I don't mean part in a vague sense: I mean you download a representation and the piece of information is in there. In many content-types you can also directly link to "sub-resources" of the resource (e.g. XML, PowerPoint, PDF)

Okay, for the sake of argument I'll concede this point because the important issue is the one above.

No, I'm not talking about better ways to perform discovery. I'm talking about better ways to express the *existing API*. i.e. we can improve it with *no new ideas* just by recasting it in terms of URIs. Same for Google. Same for any other SOAP API you can mention. If you care about technology then it should worry you that less flexible and powerful services are being unleashed on the world just to be "SOAP compliant".

That's exactly my point. POST is the perfect method for this. We *all agree* that GET should NOT be used for submitting a Purchase Order. The heart of the REST+SOAP view is that SOAP users should use the right HTTP method for the type of thing they are doing. GET sometimes. POST sometimes. PUT sometimes. DELETE sometimes. (but GET and POST as a bare minimum!)

Forget REST. Concentrate on Web architecture. One of the principles is that as many things as reasonably possible should have URIs:

"The essential process in webizing is to take a system which is designed as a closed world, and then ask what happens when it is considered as part of an open world. Practically, this effect on a computer language is to replace the names/tokens/identifiers for URIs. Thus, where before reference could only be made to something in the same document/program/module one can with equal ease make reference to something in a different one somewhere in that abstract space which is the Web."

* http://www.w3.org/DesignIssues/Webize.html

If you have a non-REST or non-HTTP way to weave this into SOAP then I would probably be satisified with that. Either way, I need SOAP to support "webizing" systems. I think this falls directly out of the group's mandate:

"The Web can grow significantly in power and scope if it is extended to support communication between applications, from one program to another. The purpose of this Working Group is to create a simple foundation to support the needs of such communicating applications."

To me, if you don't support web-izing systems then you have NOT significantly improved the power and scope of the Web. Furthermore, this is not an issue being raised late into the process. It has been raised repeatedly throughout the process.