In response to threads started on xml-dev, I wrote up the following on the topic of SOAP, HTTP, and REST.
I take the view that SOAP and HTTP are at the same level of the network protocol stack.
The more I understand about HTTP and REST the more it seems that using HTTP as a transport for SOAP is a mistake. It is convenient for SOAP, but I can see how it is at odds with HTTP and why that legitimately bothers some people. To SOAP's credit, it is not tied to HTTP, but can be easily layered on TCP/IP for use on the Internet.
SOAP has the advantage of having XML at its very core. I believe this is having profound effect on how people think about and use SOAP vs. HTTP. Some of the churn around how SOAP fits into the web may be because people intuitively want an XML based evolution of HTTP. From some perspectives (mine for example), SOAP satisfies this desire. From others, it is apparently a completely different (and horrible) thing.
SOAP's extensibility model is very different from HTTP's. The mustUnderstand attribute on headers is a vital part of that difference. So is the SOAP processing model that dictates what you do when you receive a message with content that you don't understand.
I think the SOAP extensibility model is an improvement over HTTP's. SOAP's extensibility model allows for application protocols to be layered on top of SOAP in clean, composeable, and well defined ways. In effect, SOAP is an application protocol platform.
Like HTTP, SOAP can be used to build a system in the REST style. More accurately, you would apply the interaction constraints that, when applied to distributed hypermedia systems, lead to REST to the more general distributed systems allowed by SOAP. Once the resulting architectural style is defined, SOAP headers that convey the necessary information to support that style could then be easily defined. As with HTTP, doing REST with SOAP it is a matter of discipline and understanding.
Another issue is how URLs are used to identify resources on the web. WSDL requires that a single URL identify an entire web service. Instead, a service could have an absolute base URI and each port type and operation could specify additional relative URI pieces that are composed with the base URI to construct the actual URI associated with a message. There are a number of open issues in the WSDL working group that could be addressed by such a mechanism. It could easily be used in the next version of WSDL.
Are these things enough to allow SOAP to be considered an XML based evolution on the concepts of HTTP? This is not to propose that SOAP replaces HTTP, but that a new breed of application can be built using SOAP in parallel with the use of HTTP on the web.
Comment ()
