Re: Issue 133, and permitting no body

Hi Stuart,

Nice writeup! Very clear.


On Mon, Feb 04, 2002 at 03:06:45PM -0000, Williams, Stuart wrote:
> 
> It seems to me that there are three views that we are trying to (or
> will need to) reconcile.
> 
> 	a) RPC Usage of SOAP
> 	b) Message/Document Exchange usage of SOAP
> 	c) REST/Web-Architecture friendly usages of SOAP

I'll buy that premise.


> For a): RPC Usage of SOAP
[..]
> REST/Web-Architecture, possibly, rejects this as creating
> additional 'verbs' rather than creating a richer collection of
> 'nouns' (resources) - verbing nouns rather than nouning verbs
> (nicely ironic 'nouning verbs' :-)).
> 
> So RPC usage of SOAP seems to be at odds with a REST/Web-Architecture view
> on (at least) three counts:
> 	- The degree to which SOAP messages can be regarded as
>         representations of resource state. 
>       - The creation of new verbs (whose semantics will generally be
>         unknown to HTTP intermediaries). 
>       - The use of POST for method invocations:
> 		 i) It is a stretch to regard these as a request for the
>                   creation of a subordinate (URI idenifiable) resource.
> 		ii) It may be know a-priori that the method invocation is
>                   withou side-effect in which case a GET is more 
>                   appropriate.
> 
> Alternatively, the pragmatic view is to regard RPC/SOAP over HTTP
> as 'tunneling'; to try not to reconcile this to
> REST/Web-Architecture (because at best its probably a stretch). The
> use of POST will at least enable those that wish to block RPC/SOAP
> at least a coarse grain means to do so (an more fine grained
> perhaps based on request URI matches).

Agreed.


> For b): Message/Document Exchange usage of SOAP.
[..]
> Message/Dcoument Exchange Usage of SOAP is not wholly in tune with
> REST/Web-Architecture:
> 	- It is possible to regard the entity body in the POST
>         response as representing the state of a subordinate resource 
>         (an entry in a message queue).
> 	- Modeling the POST response is a little trickier:
> 		i) It could carry a state representation for queue entry.
> 		ii) It could carry the outcome of processing the message 
>                   (not REST friendly).
> 		iii) Polling queue entry status with GET also requires a
>                    further means to de-queue or delete the entry 
>                    (lifecycle management)
> 
> Again... the pragmatic again be to regard Document/Message Exchange
> over SOAP/HTTP as 'tunneling'..

Hmm... "Message/Document Exchange" is a little broad; do you have a
slightly more specific application in mind (or an example of one)?
After all, all uses of SOAP are about 'Message Exchange'... 

The response to a POST doesn't necessarily carry a representation of
the state of the resource; often, it's some sort of status message,
or the result of processing, etc. a response to a GET for that same
resource would, of course. So, ii and iii may be REST-friendly.

I imagine that there will still be implementations along these lines
that aren't RESTful, but then again there are plenty of Web sites
that aren't RESTful either. That's OK; plenty of Web sites are
un-RESTful as well.


> For c):
> 
> Here SOAP messages would be directly seen as representations of the
> state of the resource referenced by the request URI (or its
> subordinates). Here one essentially views SOAP as syntax for
> representing resource state. This really feels like HTTP with SOAP
> as the syntax for entity bodies.

I like to think of it as SOAP just being a smarter, better media type
(which I must confess is always how I've been inclined to view it;
perhaps that's why I get confused sometimes!)


> SOAP Intermediaries raises an interesting question since they
> themselves are HTTP origin servers (that may be buffered behind a
> series of HTTP intermediaries). Each SOAP intermediary along a SOAP
> message path is an HTTP origin server. The HTTP resource referenced
> by an initiating SOAP client and each intermediary along the path
> is not necessarily the intended recipient of the SOAP message (it
> could be another intermediary).

I don't see any conflict between this and REST; they're acting as
gateways.

It's a separate issue that they may be interposed by other means
(e.g., insertion of a SOAP intermediary into a HTTP proxy), but this
is an issue that the Web as a whole is dealing with [1], and is not
specific to SOAP.


> I was thinking about Mark (B)'s suggestion [3] of using bodyless
> SOAP messages with SOAP headers being treated as more precisely
> targetted HTTP headers to control HTTP intermediaries (I making
> inferences here that may be different from what was in Marks mind).
> This feels awkward to... because unless those HTTP intermediaries
> are also SOAP intermediaries, they will not be referenced by the
> HTTP request URI and perhaps should not be 'tinkering' with the
> SOAP message.

I agree, of course.

Thanks again.


[1] ftp://ftp.isi.edu/in-notes/rfc3238.txt


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

Received on Monday, 4 February 2002 11:50:47 UTC