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

David Orchard wrote:

> 1. I believe the wording on TAG issue whenToUseGet-7 is somewhat flawed.  I
> could live with any of :
>  a. safe methods (GET/HEAD) should be used for safe operations in
> browser-centric applications
>  b. safe methods (GET/HEAD) *may* be used for safe operations or
>  c. safe methods (GET/HEAD) should be used for safe operations in web
> applications that are information oriented.

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

Received on Tuesday, 16 April 2002 01:02:24 UTC