Bill de hOra gets it

Building off of Mark Nottingham's post on POST, Bill de hOra weighs in with his missive: Slab! Interoperation and evolution in web architecture. He says something I've been trying to get across for a long while, only he says it far more eloquently.

The problem with HTTP POST, and what makes it special, is that it is a semantic catchall. What makes POST a uniform speech act is ironically the absence of interesting semantics and lack of specificity. Although it has specifications that are helpful to people when dealing with caches and state management, there's no controlled means of defining what one is actually saying with it, without some further and prior agreement between client and server. The reality is that POST has been overloaded and abused to get systems talking even where such systems would have done better with an alternate verb - and the result is that in many systems the POST speech act is close to meaningless.

Exactly! I have often resorted to the use of the famous quote from Through the Looking Glass to make this point:

'When I use a word,' Humpty Dumpty said, in a rather scornful tone,' it means just what I choose it to mean, neither more nor less.'

Bill concludes his post with the following:

Where WS-Transfer may prove useful is in breaking down barriers and getting architectural factions to the table by raising awareness that there are issues with both REST and Webservices approaches. The debate between REST/Web and Webservices/Middleware communities has often been acrimonious. Aside from complications resulting from the strategic and commercial agendas imposed by the industry that have resulted in a plethora of competing and inconsistent web services 'standards', the core technical debate has been arcane. It is not always obvious to outsiders and system stakeholders why some kind of agreement can't be forged. While the architects and vendors are busy in argument, customers and practitioners are frequently left with little by the way of clear advice on how to either construct new systems or integrate existing ones. The outcome is that systems are being built, week in, week out, than cross the Web/Middleware boundary without being informed by both approaches and where they are approriate. This implies projects with excess risks and costs, wasted effort, re-learning of best practices or what is already in the state of the art. This is all the more important now that systems that incorporate web and middleware aspects are increasingly the norm (the size of the industry sector affected is significant). Any effort that raises mutual understanding is most welcome.

Amen, brother (emphasis mine).

I have been noodling over WS-Transfer and trying to assess its impact. I am somewhat disappointed that we never did a formal mapping of a SOAP infoset to an HTTP GET in the XML Protocol WG when we were working on addressing the TAG feedback regarding HTTP GET. Instead, SOAP1.2 defines a SOAP Response MEP and a corresponding binding to HTTP GET.

At the time, I was lobbying that we should define a mapping of a particular SOAP infoset to an HTTP GET. The difference being that as with the default HTTP binding for SOAP, there would be a SOAP request and a SOAP response with the request mapped to an HTTP GET and the response SOAP message carried as the entity body of the HTTP response message. In hindsight, I should have lobbied more ardently for a mapping of SOAP onto HTTP.

WS-Transfer provides us with a Web services framework with which this might be accomplished. I would much prefer that WS-Transfer move in this direction than to continue to leverage the default binding of SOAP onto HTTP POST. Of course, this has implications for WS-Addressing as an EPR will need to be mapped to a URI and some means of conveying it's reference properties via HTTP protocol artifacts such as cookies.