W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2002

RE: Issue 133, and permitting no body

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Mon, 4 Feb 2002 19:48:32 -0000
Message-ID: <5E13A1874524D411A876006008CD059F192944@0-mail-1.hpl.hp.com>
To: "'Mark Nottingham'" <mnot@mnot.net>
Cc: "'Mark Baker'" <distobj@acm.org>, xml-dist-app@w3.org
Hi Mark,

> Hi Stuart,
> 
> Nice writeup! Very clear.

Thank you... originally set out to try to summarise, ended up developing a
point-of-view :-0

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

I'm thinking that you might not be entirely comfortable with b)...

<snip content="RPC Usage"/>

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

So... if we take the view that SOAP is indeed about 'Message Exchange' and,
presumably that RPC usages of SOAP are 'simply' layered ontop of
messaging... in which case Message Exchange is 'closer' to the metal than
RPC.

You ask if I have a particular 'specific' application in mind. The simple
answer is no... although perhaps something like ebXML is the flavor or the
sort of the thing I have in mind. Perhaps more generally something that
operates outside the RPC/SOAP paradigm and more fits with the WSDL
<soap:binding style="document"> (not withstanding the comments in [2] :-)).

Anyway, if you see SOAP as being about message exchange (which I do) then
what I was trying to do was think how you would describe that as a SOAP/HTTP
application in REST like terms... ie. what do the resources model and how
might one think of the messages as state representations - and not simply
messages. I don't know that I have it right.

> 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 agreed... but there is a tentativeness here. RFC 2616 says the following
about POST responses:

<quote>
   The action performed by the POST method might not result in a
   resource that can be identified by a URI. In this case, either 200
   (OK) or 204 (No Content) is the appropriate response status,
   depending on whether or not the response includes an entity that
   describes the result.



Fielding, et al.            Standards Track                    [Page 54]

RFC 2616                        HTTP/1.1                       June 1999


   If a resource has been created on the origin server, the response
   SHOULD be 201 (Created) and contain an entity which describes the
   status of the request and refers to the new resource, and a Location
   header (see section 14.30).
</quote>

We have to carefully think through how we want to make use of the HTTP
status codes in the context of SOAP, particularly 201 (Created).

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

:-)... so thats the pragmatic stance.

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

I'm not sure really how it improves things in this context over a
well-defined XML vocabulary targetted at representing the state of whatever
the RESTful resources are intended to model/signify/represent - except
possibly for headers targetted at intermediaries with more precision than
HTTP affords.

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

REST defines a generic interface that all resources support and is
exemplified by the HTTP protocol operations. Intermediaries get to work
because they can interpose themselves between client and origin server in
away that is transparent to the HTTP operation. Nevertheless the client
believes it is referencing a resource identified by the request URI.

I think that this is not the case with SOAP intermediaries. It is not even
clear that a SOAP client knows what resource it is actually referencing...
only that, in general, it is referencing the next intermediary along a path.
The resource that it actually references (the ultimate recipient, the
default actor...) is essentially anonymous.

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

Thanks for the reference. I'll take a look at rfc3238.

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

Nice to chat with you again... can't tempt you back into the WG :-)

Cheers

Stuart
[2] http://www.xml.com/pub/a/2001/12/19/wsdlwg.html
Received on Monday, 4 February 2002 14:48:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT