RE: [WhenToUseGet-7] Re: TAG document: SOAP HTTP GET binding avai lable

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

Received on Thursday, 16 May 2002 07:28:26 UTC