RE: Issue 133: SOAP and Web Architecture: Draft sentences for HTT P binding preamble.

Hi Paul,

Had a look at http://www.prescod.net/http/query_alternatives.html

There was one paragraph that I read repeatedly and still have trouble
getting the point of what it is saying, you may want to clarify it.

"Let's examine the case for QUERY architecturally (as opposed to
pragmatically). The idea is that sometimes you have a "lot of data" and
encoding it as a URI is inconvenient. As you can see, this is not really an
architectural issue at all. It is just as valid to have a resource like:
"www.somesite.com translated into French" (which would unquestionably use
GET) and to have one like " translated into French". And in fact there is no
good way when you are setting up a service to know whether the end-user is
going to enter a little bit of data, which should go into a GET or a lot
which should go into a QUERY. So QUERY is not architecturally necessary nor
useful. "

Its the bit around " translated into French" (2nd occurence of the phrase)
that leaves me stranded and feeling that there is something missing from the
narrative.

I think you are asking the question of, with two GET like methods
(GET/QUERY), how would does a client (forming a query) make the choice over
which one to use and... if the difference is only the size/convenience of
the query string then really its not an architectural issue, in which case
I'm inclined to agree. 

> -----Original Message-----
> From: Paul Prescod [mailto:paul@prescod.net]
> Sent: 20 February 2002 18:17
> To: Williams, Stuart; xml-dist-app@w3.org
> Cc: 'Mark Nottingham'; Martin Gudgin; Paul Prescod
> Subject: 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.

Interesting... I tend to think it as one of the most interesting issues
because it seems to be a primary functional difference. Cacheability is good
and affects performance and scalability, side-effect freeness however is an
important functional distinction. Mark B drew my attention to some of the
careful wording on this in RFC 2616.

From an exchange with Mark Baker:

>> HTTP does talk about one important issue in this respect; the 
>> safety of GET.  From 2616 Sec 9.1.1;
>> 
>> "  Naturally, it is not possible to ensure that the server does not
>>    generate side-effects as a result of performing a GET request; in
>>    fact, some dynamic resources consider that a feature. The important
>>    distinction here is that the user did not request the side-effects,
>>    so therefore cannot be held accountable for them."

> 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!

Could work for a particular data model (eg the one in part 2), but the
situation is more complex for an arbitrary SOAP message.

> > 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. 

I'm trying to find a view that could reconcile a message exchange oriented
view of SOAP with a resource oriented REST view. It maybe that this is a
futile gesture and such a view may not (usefully) exist.

> 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.

Certainly seems consistent with the 'inferior' gateway I described.

> 
>  Paul Prescod
> 

Regards

Stuart Williams

Received on Wednesday, 20 February 2002 15:54:05 UTC