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

+1 to Stuart's comments.


Williams, Stuart wrote:

> Hi Tim,
> Personnally, I prefer the Content-Location approach.
> I think that SOAP/XMLP-WG is getting 'beaten-up' on two issues:
>  i) Visibility of resources (resources SHOULD be identifiable by URI).
> ii) The availability of access to safe methods - specifying a binding to
> HTTP POST only doesn't appear to provide an option to use GET even in those
> circumstances where you want to make that choice - that said, the SOAP 1.2
> drafts, don't preclude the use of HTTP GET, they simply say nothing about
> it.
> Visibility, i), can be addressed both by the use of Content-Location and by
> the message content itself which can contain references to related resources
> (line items in a purchase order, address book entries etc.) much in the same
> way that a hypertext document contains hyperlinks. 
> Access to safe-methods, ii), IMO needs some work on the part of the XMLP-WG
> to do more than simply 'not-preclude' the use of HTTP GET, but to provide a
> pattern for its use in conjunction with SOAP.
> I also think that the TAG should focus on the articulation of Web
> Architecture and arhitectural principles. I think we can help WG's like XMLP
> in resolving issues of Web Architecture, *but* IMO the WG itself must be
> allowed to own the problem and to take responsibility for its resolution.
> Best regards
> Stuart
> --
>>-----Original Message-----
>>From: Tim Bray []
>>Sent: 15 May 2002 00:36
>>Cc: 'XML Protocol Discussion';
>>Subject: [WhenToUseGet-7] Re: TAG document: SOAP HTTP GET binding
>>David Orchard wrote:
>>>As part of the TAG resolution of TAG issue #7 [1], I've written a SOAP
>>>URI binding, aka a GET binding.
>>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

Marc Hadley <>
XML Technology Centre, Sun Microsystems.

Received on Thursday, 16 May 2002 10:53:06 UTC