Re: Primer draft with GET Additions

I am concerned about the scope of the deprecation of pure information 
requests carried as RPC, as stated in 
http://www.w3.org/2000/xp/Group/2/06/07/edcopy-soap12-part0-with-GET-additions.html#L3677.

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.

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.  General purpose queries are clearly pure information 
requests, and requiring all of these to be bound to HTTP GET may be 
unrealistic.  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.

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?

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.

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.

- Sam Ruby

Received on Sunday, 16 June 2002 17:15:40 UTC