[I'm sending this twice because due to a little laptop weirdness the first version went out dated sometime in 1969, which I suspect may cause breakage in many list handlers.]

David Orchard wrote:

I don't agree with (b). I don't believe that either "browser-centric" or "information oriented" are particularly useful partitioning criteria.

The Web Services practice that we're having trouble with is not new and was not introduced with the WS paradigm - I've done a ton of RPC-type stuff on both the server and client sides going back over the years using POST even when it was a pure info-retrieval operation, simply because the arguments were too big, ugly, and complex to fit into a URL.

Whenever I've done this I've paid at least two prices:

(a) many useful implementation tricks in the areas of caching, proxying, and so on, are ruled out because I didn't use GET (b) I can't bookmark the operation or put it in a web page without resorting to a form.

So Dan's draft, as stated, is correct. When you are doing an operation that you consider to be side-effect free, you SHOULD use GET. "SHOULD" means do it unless you have a good reason not to. "Too much input data" is in my opinion a perfectly good reason, in some scenarios.

The fact that SOAP is (a) verbose and (b) unconditionally decrees the use of POST is, given this, troubling. It means that *every* WS invocation is going to pay the two penalties I've discussed above - this will potentially have grave consequences for the scalability and robustness of Web Services deployments. For example, it seems to me that popular tools such as those provided by Akamai are going to have real trouble with Web Services traffic.

Clearly the W3C has neither de jure nor de facto authority over the legions of SOAP implementers out there. However, it is fact that in the Web architecture, there are situations where you SHOULD use GET, and the TAG ought to say so.

I agree with Dave that some larger group needs to take these issues up. Perhaps there is a way to bring SOAP into closer congruence with the Web architecture, with real performance benefits.

But in the meantime, I don't see how the TAG can responsibly fail to assert when, in the Web architecture, implementers SHOULD use the GET method. -Tim