Mapping WS-Addressing to HTTP

Stefan follows up on the permathread.

First off, with regards to:

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

I wouldn't characterize myself as not being a proponent of REST. Quite the contrary. In fact, I was advocating a binding of SOAP to HTTP GET long before the XMLP WG took up the issue from the TAG. I had proposed a slightly different approach, one that bound a canonical SOAP envelope with GET semantics to an HTTP GET. Although I'm content with what is specified in SOAP1.2 with the WebMethod, I do wish that it had broader adoption from an implementation perspective.

Stefan continues (emphasis his):

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.

Two points. First, I agree with Stefan's point in italics. That is why I was advocating the approach to a binding to HTTP GET for SOAP I described above. I will admit that there are some subtle issues with which to be dealt as have been pointed out by Noah Mendelsohn in the discussions we had in the XMLP WG at the time. However, the Cache-Control SOAP header block I described in my previous post could be mapped to the HTTP Cache-Control header for the HTTP binding as provided for in the SOAP1.2 Binding Framework. I was merely trying to point out that there is nothing inherent to SOAP/Web services that precluded caching such that the feature could be enabled in a transport-independent manner.

Secondly, to the "core issue in question": I think Stefan has captured the issue exactly right. I just disagree with his conclusion that it should be a requirement to map these features to those of the underlying layer.

In related posts, Savas chimes in with:

Wouldn't it be really nice if we had a Web Services description language to capture these "interesting and useful MEPs" for SOAP message transfers? A vocabulary that didn't promote request-response as the most interesting MEP but, instead, allowed us to describe complicated interactions?

Indeed;-)

Finally, I'm glad to see that someone appreciates my reference to Humpty Dumpty:-)