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

David Orchard wrote:
> 
>...
> 
> At least Stuart made an attempt to reach a compromise position, but I don't
> think that any of the "GET=Safe" people would accept that position.
> 
> One thing that strikes me the most is that I have never seen a case of it
> been shown that exclusive use of POST for SOAP is harmful, or can somehow be
> done better with GET.  I've heard examples given, but they are always
> browser-based examples, where humans do some kind of refresh.

These documents provide concrete examples of SOAP services that would
have been better if they had used GET:

 * http://www.xml.com/pub/a/2002/02/06/rest.html
 * http://www.prescod.net/rest/rpc_for_get.html
 * http://www.prescod.net/rest/googleapi/

I would be glad to discuss them further, probably on xml-dev.

Here is my sense of the basis of the GET for SAFE position.

 * A safe operation by definition has no significant impact on the
server or any other node, so it must deliver information on the client.

 * This implies that it is some form of information request or query.

 * HTTP has a method for information requests or queries: it is GET.

 * information made available through an HTTP GET can be referred to
through a URL/URI.

 * information made available otherwise typically cannot be referred to
through a URL/URI. SOAP certainly has no such provision.

 * URLs/URIs are a crucial part of a variety of W3C recommendations
like:
     * XPath
     * XPointer
     * XSLT
     * XLink
     * RDF
     * XInclude
     * xml-stylesheet

 * Information published through HTTP URL/URIs can be combined through
XInclude, queried and sorted through XQuery and XSLT, visually rendered
with xml-stylesheet, related through RDF, linked through XLink, pointed
into through XPointer.

 * URIs are arguably the basis of the *whole web* -- they are powerful
even when used without the standards above.

Now it is debatable what this means for SOAP. I propose three options:

Alternative 1. SOAP needs to "support GET" (kind of complicated at this
point, but probably doable). 

Alternative 2. SOAP should be re-engineered so that it is designed to
work on the Web rather than being adapted to it one feature at a time.
(idealistic but unlikely)

Alternative 3. HTTP should be used for fetch ("safe") operations and
SOAP for "other stuff." The SOAP specification could say that
explicitly. I believe that would be in line with the proposed finding on
whenToUseGet.

 Paul Prescod

Received on Sunday, 21 April 2002 01:27:15 UTC