The issue discussed in the WS-A/protocol independence permathread is whether addressing information contained in an endpoint reference (an EPR) should be required to be mapped to the appropriate element in the underlying protocol (e.g. the Request-URI in HTTP) or only to a SOAP header (e.g. wsa:To). While this may seem like an irrelevant detail, it touches on a pretty fundamental debate: the transport protocol independence of Web services.

I believe that transport independence is a great idea — it makes a lot of sense to be able to send a SOAP message via different communication channels. The problem, though, is that some of the protocols usually termed transport protocols, most notably HTTP, are application protocols. The distinction is relevant because ignoring the difference leads to ignoring a lot of the benefits of the infrastructure that uses those protocols.

The best example is the distinction between HTTP’s GET and POST. While POST can (and should) be used for arbitrary processing, a GET has clearly defined semantics, like being safe and idempotent and possibly supporting caching. Making the different semantics part of the protocol enables the infrastructure that implements the protocol to handle GET and POST requests differently.

Treating application protocols such as HTTP (or SMTP or POP3 or whatever) and transport protocols (such as TCP or UDP) like they were interchangeable is an abuse of app protocols; in fact, there’s not much of a point in using them this way at all. If an application protocol such as HTTP is used, it should be used properly.

The issue Mark raised is that if there’s addressing information at the SOAP level, it should be mapped to the appropriate elements at the HTTP level. And this should not be optional, but required.

Chris Ferris, not exactly known as a REST proponent or someone who’ll easily agree with Mark, sums it up very well:

The tension in this permathread is really about how to map application semantics to the transfer protocol. Mark would have HTTP be the application. Thus, when the semantic of a request message is “retrieve the representation of the resource identified by this URI”, that HTTP GET be used rather than a getSomething() operation tunneled over HTTP POST. That the URI of the resource be required to be the Request-URI of the HTTP request, not buried in a wsa:To SOAP header block in the SOAP entity body of an HTTP POST request message. Mark’s point is that by not leveraging the HTTP application protocol, that Web services have effectively opted out of some of the architectural benefits that the infrastructure of the Web provides.

He continues:

He’s right and he’s wrong, at the same time. He’s right that in bypassing the application semantics of HTTP by tunnelling all requests over POST, that Web services has effectively opted out of exploiting the deployed web infrastructure for things like caching of responses and thus will not scale as effectively as it might had it leveraged HTTP GET for those requests that were effectively equivalent to an HTTP GET. However, his assertion that you would have to modify SOAP to effect the optimization of caching in the context of a WS-Transfer Get in a transport independent manner is just plain wrong.

Chris then elaborates on how you could build caching on the SOAP level without requiring modification, all of which is IMHO beside the point, which would be that if all of this is already built into the infrastructure, one might just as well use it. HTTP has proven its value as being the underlying protocol of Earth’s largest application; I believe it’ll be a fine platform for most of the Web services scenarios one can think of. In those cases where it isn’t, it might make sense to build some of its features into the SOAP layer and use that instead, but it doesn’t seem very compelling to me to build up a completely new stack with roughly the same features and deploy it on top. At the very least, it should be required to map these features to those of the underlying layer, if it supports it — which seems to be the core of the issue in question.