RE: Issue 133, and permitting no body

Hello Mark and Mark,

I've just been catching up on this thread (having had a weekend away from
it!).

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

	- c) by definition regards SOAP messages as representations of 
	  the state of the resource (or a sub-ordinate resource) 
	  referenced by the HTTP request URI - this also feels like
	  a single hop view of SOAP.

What follows trys to explain why I come to these 'tentative' conclusions.
Others may get to the same point via different routes, an others may end up
somewhere else entirely.

I'll also note Mark Bakers suggestions on how we could simply resolve Issue
133 [4,5] which make sense to me.

Comments? Flames?

Regards
Stuart

[4] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0450.html
[5] http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0020.html (last
para)
--

Discussion
----------

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), retrieving (GET) and manipulating (PUT/POST/DELETE) the
state of a resource. Web principles [1] require that the resource being
referenced is fully identified by the URI used to reference it (otherwise,
we infer that there are web resources that are not identifiable by URI...).

So, if the contents of HTTP entity bodies are, or can be regarded, as
representations of the state of the resource referenced by the request URI
(or in the case of an HTTP POST request a subordinate resource that the
origin server is being asked to create) then a design is in tune with
REST/Web-Architecture, and if not there's a good chance that its not.

For a): RPC Usage of SOAP

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.

The crux of the issue with respect to this thread is whether or not there
are side-effects (at the origin server) associated with an RPC invocation
and if it is known a-priori that an RPC call will have no side effect, then
it should be invoked using GET rather than POST.

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

For b): Message/Document Exchange usage of SOAP.

It also feels like a stretch to reconcile this usage of SOAP with
REST/Web-Architecture. 

The resource referenced by the request URI could be regarded as a messaging
endpoint. SOAP requests carried in HTTP POST request entity bodies could be
regarded as complete representations of the state of a subordinate resource
- an entry in a message queue behind the endpoint and reasonably, a Location
header in the POST response could provide a URI for checking the status of
any queue entry created. 

If the POST response is used to carry an arbitrary SOAP message in the
opposite direction, this is harder to reconcile with REST/Web-architecture
because it has little/no relationship to the subordinate resource created by
the POST, although it might be possible to regard the POST response a
representing the state of an 'output' queue, a different subordinate
resource behind the end-point.

OTOH if one were to use something link the POST followed by GET polling the
status of the entry, then this does seem to fit with REST/Web-Architecture
view. As Yves notes [2], this give opportunity for a range of message
exchange patterns - although if it GET were to have a de-queing effect then
I think we'd be back with breaking GET semantics.

OTOH if the message carried in a POST response is a direct result of
processing the SOAP message carried in the POST request then it becomes
harder to sustain the view that the resource is a messaging endpoint and its
associated queue - it becomes the thing that processes the received message
and the POST response then needs to be regarded as conveying something about
the state of any (new) resource arising from such processing.

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

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. 

--

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

[1] http://www.w3.org/DesignIssues/Axioms.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0023.html
[3] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0457.html

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: 03 February 2002 01:35
> To: mnot@mnot.net
> Cc: xml-dist-app@w3.org
> Subject: Re: Issue 133, and permitting no body
> 
> 
> > Whoa; where was it said that #2 was about
> > SOAP-requests-in-HTTP-responses (did I miss it)?
> 
> Ok, ok.  I took it to be implicit from what I was trying to 
> achieve, and
> what you wrote as #2;
> 
> ] 2) GET w/o any SOAP envelope, response carries envelope
> 
> I don't see that as constituting a GET binding.
> 
> Anyhow, no biggie.
> 
> MB
> -- 
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@planetfred.com
> http://www.markbaker.ca   http://www.planetfred.com
>

Received on Monday, 4 February 2002 10:07:26 UTC