Re: Primer draft with GET Additions

Sam Ruby says:
> I have no problem with a more scoped recommendation, say, limited to 
> retrieval of an information resource.  The example provided in this 
> section meets this criteria as the request is for a specific 
> reservation.

But the very point of the recommendation is to guide people into the
discipline of treating all or almost all side-effect-free information
requests as retrieval of a representation of an information resource.

"Safe operations (read, query, view, ask, lookup, etc.) on HTTP
resources SHOULD be implemented using GET because that allows the result
documents to be identified by URI, while using POST does not. Also, it
is useful for server to use a safe operation since clients can take
advantage of safety guarantees made by the protocol."

 * http://www.w3.org/2001/tag/doc/get7

So we are in danger of going around in circles. We *want* people to
rethink their applications in terms of resources with URIs because that
is the Web model and SOAP over HTTP is a Web protocol. People using it
will have to think as web designers and will have to model their
side-effect-free retrieval operations as GETs of representations of
resources.

> Keeping with the travel reservation application theme, it is worth 
> noting that systems such as www.aa.com use HTTP POST for requesting 
> general queries, e.g., searches for available flights based on 
> schedules.

This is easily done with HTTP GET. Frontier Airlines does it that way.
The Frontier way allows bookmarking and mailing the link to someone
else. What benefits would a side-effect-free POST way provide?

I believe American uses session IDs so that they can track users. The
creation of a session ID is a side-effect so the use of POST would be
appropriate.

> ...  In the case of SOAP, such a restriction is likely to be 
> problematic unless the the scope is limited to an RPC style request, 
> with no complex (structured) parameters and no headers, and where the 
> total request is limited to approximately 4K of data.

I think different people have different interpretations of the term
"RPC" so I won't answer that directly. 

The transaction must use a request-response style. Complex parameters
and headers can, in my experience, always be translated into URIs -- if
not by the SOAP implementation then by the service designer. The 4K
limit is historical and I do not think it reflects the reality of
deployed software.

> It is also worth noting that enforcing these additional restrictions 
> places a complexity and runtime overhead burden on implementations. 
>  Contemplate a idempotent procedure which, in general, does not meet the 
> above criteria, but depending on the value of a parameter (a nil 
> structure or a short string) a particular request may fit within these 
> constraints.  If the recipient is known to handle the general case, what 
> is the rationale for requiring all the additional remarshalling of the data?

Either the SOAP operation does, in general, meet the requirements for
GET or it doesn't. I don't think that individual messages should be sent
via GET or POST depending on their internal structure, any more than an
HTML form would decide its method based on form fields.

> Clearly, I foresee as common practice the providing of both an HTTP GET 
> and an HTTP POST binding for idempotent portTypes. This would follow the 
> common practice for HTML FORMs.

Most HTML forms choose one or the other in the METHOD attribute. One
reason to discourage using POST to do something also available with GET
is that it will disable caching.

> When all is said and done, I suspect that it is much easier to define 
> when GET bindings should be used than when POST bindings should not.

Maybe, but the sets are mutually exclusive so defining one defines the
other.

Anyhow, the text you disagree with is merely a restatement of the
relevant TAG finding in a SOAP context!

 Paul Prescod

Received on Sunday, 16 June 2002 18:27:00 UTC