Re: SOAP and the Web architecture

Some thoughts to add to the fire;

On Thu, Aug 23, 2001 at 05:23:11PM -0400, Hugo Haas wrote:
> There has been a fair amount of discussion regarding SOAP and the Web
> architecture[7] / REST principles[6] in different forums those past
> few days, and I realized that despite this question was mentionned (at
> least) twice in the past[1,2], it never made it to the issues list
> (unless I missed it). Some recent discussions can be found at [3].

This is something that the TAG should be involved with; IIRC
they should be up and running sometime soon, no? 

[7] is stated as a 'personal view'. Albeit, *Tim*'s personal view,
but a personal view nevertheless. Seems worth putting in
perspective, esp. with the TAG coming down the track.


> The gist of the problem is that the current HTTP binding uses HTTP POST
> requests. However, sending an HTTP POST requests to a URI have precise
> semantics[4]:
> 
>    The POST method is used to request that the origin server accept the
>    entity enclosed in the request as a new subordinate of the resource
>    identified by the Request-URI in the Request-Line. POST is designed to
>    allow a uniform method to cover the following functions:
>       - Annotation of existing resources;
>       - Posting a message to a bulletin board, newsgroup, mailing list,
>         or similar group of articles;
>       - Providing a block of data, such as the result of submitting a
>         form, to a data-handling process;
>       - Extending a database through an append operation.

I don't know if I'd call these 'precise' semantics; indeed, they're
intentionally somewhat vague IMHO. For me, the crux of it is
expressed in [7]:

  [regarding idempotent messages and GET] Only by sticking to this
  rule can such systems interoperate with caches and other agents
  which exploit the repeatability of HTTP GET of URI dereferencing in
  the future.

I.e., "it's the caching, stupid", among other things.


> SOAP messages carried in an HTTP POST request may have the semantics
> of an HTTP GET request for example, and using HTTP POST in that way
> can be inappropriate.

To fix this, AFAIK we'd need to define a binding that used
request-URI encoding for the envelope in the message bound to the
HTTP request. Obviously, this would cause some problems with URI
length (many HTTP implementations limit request-URI length as a means
of avoiding denial of service). 

What's not so obvious, until recently, is that doing so would also
require the exposure of an idempotency property in the HTTP binding.
The correct setting of this property would be mandatory to fulfil the
requirements for POST and GET messages. It would not be optional.

Is it an issue to allow transport bindings to require a
binding-specific property to be set? I'm not sure, but it does give
me pause, in relation to our requirement to be transport-independant.

On a larger scale, I wonder if it's worthwhile to go through such
contortions to conform to an application-specific architecture
(Web-over-HTTP) when we're designing an application framework
designed to sit on top of it and other application and transport
protocols. The semantics (including caching; working on that one as
we speak) can be expressed in a Module, giving greater independence
from the underlying transport, and more exact and appropriate
controls.

Open issues for the group include deciding whether we will use port
80 and an HTTP URI scheme when the underlying protocol is HTTP; the
fate of this issue is intertwined with these.


> Another aspect is that doing RPC requests over HTTP POST targetted to
> a generic resource (say <http://example.com/genericSoapProcessor>) is
> also incompatible with the REST principles.

I agree that if one wants to usefully discriminate between services
(e.g., methods), they should be on different URIs.

I sympathise greatly with REST, from what I've seen of it so far; to
me, it highlights that a system must be designed with a view to how
it will be used in mind, something that I agree with strongly.

I do scratch my head, however, at the attempted application of REST
to SOAP. I won't say more until I get a bit more up to speed on it ;)


>   1. http://lists.w3.org/Archives/Public/xml-dist-app/2001Jan/0029.html
>   2. http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0090.html
>   3. http://lists.w3.org/Archives/Public/www-archive/2001Aug/thread.html#25
>   4. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
>   5. http://www.w3.org/DesignIssues/Axioms.html#state
>   6. http://internet.conveyor.com/RESTwiki/moin.cgi/RestResources
>   7. http://www.w3.org/DesignIssues/Axioms.html

-- 
Mark Nottingham
http://www.mnot.net/

Received on Thursday, 23 August 2001 19:53:07 UTC