[WhenToUseGet-7] Re: TAG document: SOAP HTTP GET binding available

David Orchard wrote:
> As part of the TAG resolution of TAG issue #7 [1], I've written a SOAP HTTP
> URI binding, aka a GET binding.
> 
> http://www.w3.org/2001/tag/doc/ws-uri.html

There are two different technical choices which both achieve our goal 
here.  The first is what I originally proposed and Dave has fleshed out 
nicely in the document above: mechanically map some class of SOAP 
request messages into GET-able URIs.

The second is due originally to Roy Fielding - simply require that for 
operations which are safe, the response to a SOAP request include a 
"Content-location:" header that gives an appropriate URI, which can be 
any old opaque syntax convenient for the server.  You'd have to POST the 
request once to get this, but then you'd have it forever.

The content-location approach is probably more elegant and generalized, 
but I favor the simple URI encoding for a couple of reasons.  First, a 
server-side module can easily reverse the URI-encoding and hand the 
service software a SOAP request packet so it need never know what has 
happened; thus a bit of software in the top 5 popular web servers will 
provide URI addressability in all applications where it's appropriate 
for a very small investment in effort.

Second, I worry about time issues... for services whose results are 
time-dependent, does the content-location URI refer to the resource 
representation at some particular time, or should it, or should that be 
an optional feature, or what?  The mechanical URI encoding makes these 
issues go away.

On the other hand, the content-location approach makes the problem of 
who determines whether an operation is "safe" or not just go away - if 
it's safe you get a content-location back, otherwise not.  However, I 
worry that many implementors will just be lazy and not do the work of 
generating the content-location even for safe things.  -Tim

Received on Wednesday, 15 May 2002 01:20:37 UTC