Re: XML Protocol and Axioms of Web Architecture

Hi Aaron.

I am copying Yves Lafon who is also Team contact for the XML Protocol
Working Group, Mark Baker, who discussed this in a paper and with whom
I talked privately, and Eric Prud'hommeaux, with whom I talked about
this too.

* Aaron Swartz <aswartz@upclink.com> [2001-08-15 18:14-0400]
> Dan Connolly and I were talking about Web Services and Web 
> Architecture on #rdfig today[1] and the issue of XML Protocol 
> came up. I had previously asked the Working Group about their 
> intentions with regards to preserving the semantics of Web 
> Architecture and received no response:
> 
> http://lists.w3.org/Archives/Public/xml-dist-app/2001Jan/0029.html
> 
> Dan Connolly claims to have "asked (indirectly) for a GET (i.e. 
> REST) related requirement for the XML Protocol requirements".
> 
> I was curious if the Working Group has adopted this as a 
> requirement, and if not, why.

First, and to answer your question, I relayed this concern[10] and
this fell off my radar screen before it made it to the issues list or
was discussed enough.

I did a bunch of reading from the FoRK archives[2], xml-dist-app[3]
and a very interesting text by Mark Baker[4].

Note that the discussion below is based on the current HTTP binding of
the SOAP Version 1.2 specification[5], i.e. an XML document as the
entity carried by an HTTP POST request.

Abusing the Web architecture is easy and frequent. The same way Web
designers use HTTP POST instead of GET in HTML forms for everything
(e.g. what is the most played song on radio stations in Dallas, TX
over the last week), you can use SOAP in the POST request to do the
same.

The drawbacks are two-fold: first, POST is used whereas there is no
side-effect to the query (I am not committing or changing any
information), and second you are likely to talk to a generic (e.g.
<http://example.com/mySoapProcessor>) which has nothing to do with a
resource representing the list of most played songs on Texan radio
stations.

In simple cases, such as the ones described by Mark (i.e. direct
communication between the client and the server), SOAP only makes
sense over POST, using the semantics of POST, and I think that it is
up to programmers and system designers to use the Web as it was meant
to be used.

However, there is a gain in using a SOAP request (in an HTTP POST
request, as currently stands) instead of a simple GET: you get a
processing model, including the fact that you can use intermediaries;
e.g. a third party (key escrow) could authenticate my request in some
way and add some information along with my request and send it to the
final recipient afterwards.

The problem with this is that such an HTTP binding forbids HTTP
intermediary caching.

HTTP POST requests are not cacheable. Moreover, it does indeed
challenge the architecture of the Web[8]. I originally thought that it
was meaning that SOAP Version 1.2 did not meet requirement R803[7],
but I don't think that this is the case.

HTTP GET requests do not have an entity body. POST requests do.
Nevertheless, you could encode your SOAP request in some way in your
GET request, by using, say a 20k-long URI; [6] suggests however that
current HTTP implementations will not really like that.

Moreover, if you want to use an intermediary, you would still have to
to use URIs in a weird way for routing (i.e. the client will not send
a request to the final recipient):

   client
   -> (first hop to the key escrow)
   http://key.escrow.example/key?user=hh&target=<put_encoded_soap_request_here>
   -> (second hop to the server hosting of the list of top songs)
   http://example.com/top%20songs?request=<put_encoded_soap_request_here>
   -> (response sent to the client)

In the end, I wonder if this "tunnelling" of SOAP in HTTP is really
worse than using GET requests (see also Mark's proposal of two
bindings[9]). I think that the advent of SOAP makes use of the Web in
a new way, which might be fine as long as 1) we are aware of it 2)
this is the way to go 3) we clearly document it.

[ I will stop here for tonight, because I don't think that I will
  solve the problem tonight... ]

I am proposing (in a separate email, sent to xml-dist-app) to open two
issues refering to this email:

1/ The HTTP binding of the SOAP Version 1.2 specification[5] does
   preclude caching of information at the HTTP level in case of
   requests having the semantics of an HTTP GET request.

2/ SOAP Version 1.2 over HTTP[5], in its current form, misuses the Web
   architecture. There is a risk of abuse of the HTTP POST method over
   a single URI (e.g.
   <http://example.com/IWillDoAnyProcessingYouNeed>).

I would appreciate some input before I do so, so that we don't open
unnecessary issues.

  2. http://xent.com/pipermail/fork/
  3. http://lists.w3.org/Archives/Public/xml-dist-app/
  4. http://www.markbaker.ca/2001/07/SoapUses
  5. http://www.w3.org/TR/2001/WD-soap12-20010709/#_Toc478383526
  6. http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0096.html
  7. http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#z803
  8. http://www.w3.org/DesignIssues/Axioms.html#state
  9. http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0241.html
  10. http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0090.html
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092

Received on Friday, 17 August 2001 21:20:57 UTC