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

+1 to Stuart's comments.

Regards,
Marc.

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 [mailto:tbray@textuality.com]
>>Sent: 15 May 2002 00:36
>>To: xml-dist-app@w3.org
>>Cc: 'XML Protocol Discussion'; www-tag@w3.org
>>Subject: [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
>>
> 


-- 
Marc Hadley <marc.hadley@sun.com>
XML Technology Centre, Sun Microsystems.

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