We get comments...

Carlos, in comments to my previous post writes (emphasis mine):

I think we're going to see the argument "SOAP is orthogonal to REST" repeated again and again. In the beginning the SOAP adherents were full of disdain against REST, now they want to play in the same playground!

According to Chris Ferris definition SOAP is "defines a message structure (the SOAP envelope infoset), a set of rules for processing SOAP messages, and an extensibility framework." If this is the new definition, then I would like to hear a simple explanation on how all this baggage helps improve interoperability. Now if SOAP doesn't say anything about interoperability (i.e. it is orthogonal to REST) then a clear consistent and coherent explanation of WS-* would help.

To the first highlighted point; painting all of the so called SOAP adherents with the broad brush of "disdain" for REST is both unfair and unjustified.

Henrick Frystyk Nielsen (a contributing author of the HTTP specifications), Noah Mendelsohn, and Don Box, some of the original authors of the SOAP specification, each (I believe) have a deep respect for Roy's thesis as well as a deep understanding of the Web. Other members of the XMLP WG whom (I believe) have always held REST in high regard, and have consistently maintained that SOAP and REST are complementary include Dave Orchard, Stuart Williams, Marc Hadley, Glen Daniels, and myself to name but a few. Certainly, I would put Sam Ruby in the category of those who have consistently maintained this position.

To the second point; that definition of SOAP is not a new definition by any stretch of the imagination. RTFS. If the fact that I cite SOAP1.2 as opposed to SOAP1.1 is a problem, then consider that most implementations of SOAP (generic) have been greatly influenced by the SOAP1.2 W3C Rec and by the WS-I Basic Profile which itself was heavily influenced by the work of the W3C XMLP WG. If you are still not convinced, then here's the intro to SOAP1.1 (emphasis mine):

SOAP provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. SOAP does not itself define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules. This allows SOAP to be used in a large variety of systems ranging from messaging systems to RPC.

Where SOAP adds value from an interoperability perspective is in its extensibility (soap:mustUnderstand) and processing models. It provides a framework that enables gradual evolution of widely deployed services to add features, such as the ability to digitally sign a message, wherein the new feature(s) can be either safely ignored by the SOAP receiver (mU='false') to which the feature is targetted (soap:actor|role), or be designated as mandatory (mU='true').

If you don't believe you need this, then by all means, don't use SOAP. No one is twisting anyone's arm.