W3C home > Mailing lists > Public > www-tag@w3.org > May 2002

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

From: Paul Prescod <paul@prescod.net>
Date: Tue, 21 May 2002 04:50:35 -0700
Message-ID: <3CEA348B.1A3CC7D6@prescod.net>
To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
CC: "'Tim Bray'" <tbray@textuality.com>, www-tag@w3.org
"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
Received on Tuesday, 21 May 2002 07:50:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:51 UTC