Re: Issue 133: SOAP and Web Architecture: Draft sentences for HTT P bi nding preamble.

"Williams, Stuart" wrote:
> 
> FWIW... there was discussion at the recent TAG F2F of the possibility of
> defining a new QUERY method for HTTP. The following is an extract from IRC
> Log which is publically visible at [1] (PaulC also mentioned this on
> last-week's WG call):

I both believe and pray that this will not happen. Anyhow, this brief
dialog is enough to get people thinking about it but I will not believe
that it will really happy until I hear HTTP wonks like Roy Fielding, Jim
Whitehead and Mark Baker sign off. I don't believe they will. 

Nevertheless, it is irrelevant unless the SOAP HTTP binding allows
people sending messages to choose their HTTP method which I do not
believe it does today.

http://www.prescod.net/http/query_alternatives.html

>...
> In the long run this would seem like the right approach to me... to define a
> new 'idempotent' method for HTTP that has GET with body like semantics.

GET can have a body already. The point is that *all* resources on the
Web should have URIs. So if stock quotes are on the Web then they must
have URIs, whether they are accessed through FTP, HTTP or SOAP. If
purchase orders on the Web then they must have URIs. This is one of the
fundamental axioms of the Web.

GET with body (whether called QUERY or not) does not help.

> However, as you see accomplishing that would involve liason with the IETF
> and is certainly outside the scope of the current XMLP-WG charter. In the
> long run it would give the means to 'efficiently' carry a SOAP envelope in
> an HTTP request AND signal that operation is (intended to be) without
> side-effect. In effect it would be an HTTP away to carry an idempotency
> property outside of the SOAP envelope.

Side-effect freeness is the least interesting issue. Think of it as a
proxy. We could define a POST header for side-effect freeness (maybe
there is one...know there are some about cacheing). The reason that
side-effect-free methods must go through GET is because that way they
form a URI space. And that URI space *is* the Web. Putting junk in the
body doesn't do that.

>...
> In the meantime, URL encoding of SOAP envelope feels like a horrendous
> kludge...

It would make no sense whatsoever to URL encode the SOAP envelope. Query
parameters are used to address the thing you want to get out of the
resource. So SOAP:Envelope is irrelevant. Doesn't have to be URI-ized.
SOAP:Headers don't have to be URI-ized. The body does, but not as XML.
Consider what XForms does:

"Instance data is urlencoded with the following rules:

Each element node is visited in document order. If the element contains
only a single node, it is selected for inclusion. Note that attribute
information is not preserved.

Elements selected for inclusion are encoded as "EltName=value;", where
"=" and ";" are literal characters, "EltName" represents the element
local name, and "value" represents the contents of the text node. Note
that contextual path information is not preserved, nor are namespace
prefixes, and multiple elements might have the same name.

All such encodings are concatenated, maintaining document order. The
resulting string is urlencoded, as in HTML processing"

If you (and they) would separate out your data model from your syntax
then this would be even easier. XML is *just a data format*. If it gets
in the way, get rid of it!

> There is separately, the philosopical question of how much of the underlying
> protocol you want to make visible to a SOAP user. I think I can live with
> the notion that an application might signal that a given exchange of
> messages is intended to be without side-effect. How that would then be
> expressed in an email or TCP/DIME like binding (perhaps slips into the
> envelope somewhere - a header?) remains open.

Yes, maybe there is a per-protocol header.

> There is also a possible alternate view... that SOAP is about an exchange of
> messages; that the web resources referenced by request URIs represent
> message queues; that the POSTING of a SOAP message request that referenced
> queue accept the POSTed message as a subordinate of the queue entry; of
> course this hides any material effect that the processing of the message by
> intermediaries and endpoints, but it is a way to (begin-to) reconcile a
> message-oriented SOAP view with a REST oriented view.

What you're describing is what the HTTP specification calls a "gateway".
And what you're saying is that all information in a SOAP component is on
another networked that is "gatewayed" to the real web. Only you are
describing a very poor gateway because a decent gateway (like
groups.google.com) gives a GET-able web URI to every data object that is
addressable through the gateway. You propose to have everything
gatewayed through a single URI. 

But it isn't accurate to say that SOAP is creating another gatewayed
network beside the Web, because these gateways are not mutually
addressable. So SOAP is creating N networks beside the Web where N is
the number of SOAP endpoints in the world.

 Paul Prescod

Received on Wednesday, 20 February 2002 13:19:59 UTC