Re: Issue 133, and permitting no body

On Mon, Feb 04, 2002 at 07:48:32PM -0000, Williams, Stuart wrote:
> 
> 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.

OK; that's roughly what I thought. All I think the WG needs to
consider is how to make it possible to use HTTP in a RESTful fashion
when using SOAP with it; people can then choose whether or not to
take advantage of it, just as they would any other underlying
protocol feature. Some forms of message exchange may make this
difficult.


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

Yes. I used to think that it was unwise to enumerate all of the
SOAP-specific semantics of status codes, etc., but have had something
of a change of heart; they aren't self-evident to many,
unfortunately.


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

So there are two issues here; making SOAPs use of HTTP RESTful, and
makeing SOAP itself RESTful. You seem to be concerned with the latter
here. I'd be happy with the former ;)

I think I'd view SOAP intermediaries as resources that perform an
operation to an encapsulated message. That message's semantics happen
to tell it to access another resource, and so forth. There are
implied semantics for the processing of the response, which include
interpretation of the response itself. 


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

Alas, it's out of my hands.


Cheers,

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

Received on Monday, 4 February 2002 19:12:37 UTC