Re: Issue 133, and permitting no body

Good job Stuart!

> 	a) RPC Usage of SOAP
> 	b) Message/Document Exchange usage of SOAP
> 	c) REST/Web-Architecture friendly usages of SOAP
> [I'm just testing the water here and below]
> To save you the bother of reading another ramble on my part (Discussion,
> below) here are some tentative conclusions:
> 	- Neither a) or b) are fully in tune with REST/Web-Architecture 
> 	  (even with GET added) and pragmatically are probably best 
> 	  regarded as 'tunnelled' usages of HTTP.

I agree, but also agree with MarkN that b) is a bit vague.  The
important aspect of REST here, is that the message is sent using the
application semantics of HTTP.

> The REST/Web-Architecture view of a the world is that the world is full of
> resources identified by URIs; That HTTP is used to transfer representations
> of the state of a resource (not the resource itself) for the purposes of
> creating (POST),

"creating" isn't the best description of what POST does, because PUT can
do it too.  "accepting as a subordinate" says it all, I believe.

> One can regard the request URI as referencing a resource that performs a
> number of operations (based on the content of SOAP messages sent to that
> resource). These operations are not the GET/PUT/POST... of HTTP, they are a
> set of implementation/deployment dependent procedures/functions. To see the
> content of SOAP messages as representations of resource state you could
> perhaps look at them as some form of state delta's... rather than
> representations of complete state... but that does seem a stretch.

Big stretch. 8-)  They also require additional agreement to be made over
the wire.  i.e., it's no longer sufficient that two parties agree on
what POST means, they have to agree on what the method name hidden in
the POST means.

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

For sure.

> 	- The creation of new verbs (whose semantics will generally be
> unknown to HTTP intermediaries).

REST doesn't say that adding new verbs is a bad thing, it only says that
if you add them, they have to apply to all resources.  i.e. I shouldn't
create a method called "getStockQuote", because that only applies to
stock quotes, not to chickens or golf balls.

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

As above, POST is more than for this.  Have you seen my I-D?

> 		ii) It may be know a-priori that the method invocation is
> withou side-effect in which case a GET is more appropriate.

.. and is a retrieval method.  Tim's axioms need some fixing up, IMHO,
especially the one referenced by issue 133;

I talk about this here;

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

Right.  I have to disagree with MarkN's response to this; any 2xx
response to a POST includes a representation of a resource (even 204).
It's just that the resource is so transient that there's no point
providing a URI for it in most cases (and if there is, we can use 3xx
to redirect to it).

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

Well, the SOAP headers wouldn't be treated any differently than they
would be over POST (in a REST friendly way).  That is, they can be
logically used as HTTP headers by SOAP/HTTP nodes.

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

Right.  What's the issue?  A SOAP binding to GET would require that the
HTTP intermediaries are also SOAP intermediaries.  We expect that of
POST, so why not GET?  There is the issue that HTTP intermediaries that
aren't SOAP intermediaries won't know what a mandatory GET is - I
mentioned this before.  Practically, it may mean another GET-like
method, but as long as that method is defined in terms of HTTP GET (like
M-GET is), I don't see a problem.

Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.

Received on Monday, 4 February 2002 14:51:43 UTC