|Subject:||Getting no REST|
|From:||Mark Baker (dist...@acm.org)|
|Date:||Mar 5, 2002 8:04:11 am|
[I know this looks a bit long, please bear with it up to the end of the second of the two following paragraphs before filing in the usual place - Thanks]
So... I think we are yet again running up against the tensions between the 'tunneling' and 'chameleon' views of SOAP. I'm not sure that I believe that these two views can be accomodated within a single binding... but I have a thought with respect to the 'chameleon' view applied in the context of HTTP - which I'll try out here and see if I get buried under a tonne of rubble ;-)
I think that it would be possible to regard a SOAP message simply as a content-type (application/soap+xml) along with a model for processing that content-type (the SOAP part 1 section 2 processing model). Move SOAP messages around in HTTP and you are doing HTTP.... no-binding required... you're doing HTTP and normal HTTP semantics apply - and the SOAP messages are in some sense (although I don't know what) resource representations. This gives you access to all the HTTP methods and (I think) requires no definition of a binding. Of course in the process SOAP ceases to be a protocol (in this view), it becomes a content-type and a processing model.
No, it's still a protocol, in that mustUnderstand, actor, and the end-to-end model defined with them, comprise extended agreement required to permit a priori communication. This is (roughly) the definition of a protocol.
A litmus test of whether something is a protocol or not, is whether the thing has faults. If it does, it's a protocol. If not, it isn't. This works because faults are a by-product of agreement.
In the other view, the 'tunneling' view, folks very much see SOAP as a protocol for exchanging messages and they want to be somewhat agnostic to what underlying protocol SOAP is bound to, much in the way that folks can be (mostly) agnostic about what the data-link technology IP is bound to. In this view folks conceive of themselves as exchanging messages (SOAP messages) between endpoints (which process messages) identified by URIs. In this 'view' the messages are not considered to be representations of resource state (representations of the state of an endpoint) - they are messages exchanged between entities bound to those endpoints. This view requires a binding, because it is *not* doing HTTP, its is doing Message Exchange over HTTP (tunneling).
These two views re at odds because the 'chameleon' view seeks to expose HTTP as fully as possible and in the limit SOAP/HTTP is HTTP (full-richness) whereas the 'tunneling' view seeks to abstract away from or 'hide' HTTP and avoid exposing details of the underlying protocol to the thing (application entity) using SOAP.
That's a good characterization. Another way of saying it is that the chameleon view exposes the application model in use, whereas tunneling hides it.
I think this explanation goes a long way to explaining why the tunneling view disregards Web architecture. The Web is an application, and tunneling over it disregards that application and all the rules and constraints that were built into it (Tim's axioms).
So we have two communities (at least) pulling toward these different extremes.
I think that one reasonable viewpoint is that one can 'do' HTTP and simply(?) use SOAP for the content-type of the of an HTTP request/response entity body. This *is* HTTP, no binding required.
A binding is required in the chameleon view because 1) you have to know how to map SOAP faults into the fault model of the application protocol, and 2) you have to know which parts of the application model of the underlying protocol is being reused. For example, we currently only define a POST binding, which means that we can't do replacement-type stuff, since HTTP PUT is required for that, nor can we do retrieval, since GET is used for that.
However, in the Messaging/Tunneling view you do need a binding to establish how messages are exchanged between messaging endpoints. Of course you then need to establish the (binding independent) semantics of your messaging system (what messaging operations does it support and what are their semantics)
Ah, see, there's the rub. Application protocols *already* define those semantics for you (some being more general than others). The chameleon view reuses them, whereas the tunneling view ignores them and reinvents new ones.
- and an account that describes how the semantics of message transfer are accomplished as a pattern of resource state manipulations. eg. these resources represent intermediary-points and end-points in a messaging system, and that the effects of HTTP are to transfer messages that are either immediately processed yielding an immediate result (200), or that are accepted as subordinates (201) (an entry in a queue at the endpoint).
I have a concern that we may be trying to align messaging semantics and HTTP semantics so tightly that ultimately we fail to define a messaging system and all we end up with is SOAP as a content-type for HTTP.
I don't know what a "messaging system" is, nor do I believe the WG could ever agree on that.
Also, as I've tried to reiterate many times, I'm not trying to align anything with HTTP semantics, except for the HTTP binding. I'm trying to say that the big value add of SOAP is where it is used in a way that, at each hop in a path, reuses the application model in use for that hop.
An example ...
Suppose I want to build a SOAP/HTTP based interface to email. I would build a SOAP/HTTP node that accepted a message in over POST, and then sent it out over DATA. So I could do;
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" > <env:Body> Hi Stuart, how are you? </env:Body> </env:Envelope>
and then my software would convert that to;
HELO marks-email-gateway.markbaker.ca MAIL FROM: dist...@acm.org RCPT TO: sk...@hplb.hpl.hp.com DATA [headers..] <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" > <env:Body> Hi Stuart, how are you? </env:Body> </env:Envelope> .
That's what a SOAP HTTP/SMTP gateway would do. The value of SOAP as a protocol here is the extended end-to-end model; that I could include extension headers that I require that your end understand (assuming your receiving SMTP processor dispatches on one of the headers we included - note to self, see what email binding does here).
For sure, and I'd rather not have to enumerate these. That's why I think it's easiest to use broad strokes and say that *if* a response includes a body *and* uses any 4xx or 5xx response code, then it is a fault ...
So wrt 4xx status codes, 2616 states:
<quote> Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user. </quote>
I think that there is a mismatch of expectations here if the entity body is a SOAP fault ;-)
How so? You mean the "display" bit? It's not hard to build a browser plug-in, or an intermediary, that could display a fault.
I agree that there are different POVs, and that MUST is the right conformance level here, but that still doesn't say what the authoritative determinant of a fault is.
Well, it would say that one party is non-compliant... ie is broken. They are in error. If you proceed at all, proceed with caution. Maybe throw your hands up in horror and refuse to play because you have received something invalid... as broken as badly formed XML.
One could produce a ruling one way or the other for these non-conformant cases, but which way to make the rule is open to debate.
Hmm.. But there's no "parties" here, it's a single message that asserts two conflicting things; "I'm a fault", "I'm not a fault".
Are you suggesting that a fault be generated if such a fault is received?