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

"Williams, Stuart" wrote:
> 
> Hi Tim,
> 
> Hmmmm... my preference for the 'Content-Location' approach is because it
> works regardless of the style of SOAP message in use.
> 
> The proposed URL-encoding approach works for some subset of SOAP messages
> that 1) fit the RPC conventions and 2) have only 'simple' parameter values.

The content-location approach is not, IMO, sufficient because it does
not provide an algorithm that a SOAP intermediary can use to decide
whether to use HTTP GET for a particular hop in the message's journey.
By the time you get the content-location, it is too late. You already
did a POST of something that was logically a GET. You've already
confused proxies and other intermediaries. Furthermore, someone writing
directly to the service has no way of generating a correct URI on the
client side.

> We could debate whether this hits a 60-40 or even 80-20 point - but unless
> we work on a URL encoding for almost arbitrary XML, there will be resource
> identifying SOAP messages that cannot be encoded into a URL.

I guess it just depends on how you look at it. My point of view is that
the resource identifiers should be chosen such that they fit into a URI.
If you are generating resource identifying messages that cannot fit into
a "universal resource identifier" then I think you are doing something
wrong. A point of departure for the "Web architecture" folks versus of
the "SOAP folks" is that I think that every SOAP message should be
generated with the web architecture in mind.

 Paul Prescod