RE: Issue 133, and permitting no body

Hi Mark,

> Good job Stuart!

Thanks.

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

Ok... the point I was trying to get at was that 'subordinate' resource is a
different resource from the resource referenced in the request URI... I
guess unless you regard a resource as being subordinate to itself. 
> 
> > 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.

To some extent I thing this is a little over-played. In order to get
something done we still have to know the 'significance' of a resource. To
have a useful effect (or side-effect) we can't just POST any old thing... we
have to know what the resource signifies and what vocab to use for its state
representations... which in my book is an additional agreement over and
above what HTTP provides.

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

Practically I think it really amounts to the same thing... not a bad thing,
per-se, but requiring of substantially more agreement than the deployment of
a new resource.

> 
> > 	- 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?
> 
> http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model

I have spotted it, and skimmed it briefly... but need to give it a proper
read.

> > 		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;
> 
> http://www.w3.org/DesignIssues/Axioms.html#GET2

Well, whilst there may be input arising from this discussion, fixing up
Tim's axioms goes a little beyond the scope of what this WG is chartered to
do. Maybe a TAG dependancy ;-)

> I talk about this here;
> 
> http://lists.w3.org/Archives/Public/www-tag/2002Jan/0075.html
> 
> > 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.

Except perhaps for the ones that aren't SOAP intermediaries :-)

> We expect that of POST, so why not GET? 

I don't think that we do (expect SOAP intermediaries to be HTTP
intermediaries)... I think in the context of SOAP a SOAP intermediary is an
HTTP origin server. There may be HTTP intermediaries between SOAP nodes. 

> 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.
> 
> MB
> -- 
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@planetfred.com
> http://www.markbaker.ca   http://www.planetfred.com

Regards

Stuart

Received on Monday, 4 February 2002 15:50:45 UTC