Having looked at various SOAP toolkits in the Java world, and C#.NET’s implementation in a previous life, I’d say that this is an important capability to look for when choosing a web services stack (where the stack might well include the choice of language as well as toolkit).

Firstly, thanks for taking the time to leave such an extensive comment. It is greatly appreciated.

Your comment about the overhead of SOAP ties in exactly with what I was saying about the complexity of the request. If the request is complex (and no doubt large) you will no doubt be better off using SOAP and the overhead will indeed be a negligible amount.

In regards to your comment: “This is a much more serious misconception as it confuses the messaging protocol (SOAP) with the databinding layer” – I’m not sure I agree with this. While what you are saying is correct, this article is intended to be related to the practical implementation of SOAP/REST in PHP. In PHP this is a definite problem with the SoapServer class and no doubt many other SOAP toolkits have similar problem or incompatibilities. Whether it is an issue with the SOAP specification or not (I am not suggesting it is) is irrelevant.

“The volume of traffic that will be going through the API. SOAP will have a greater overhead than REST.”

Per-message, yes — so if you’re handling a large number of small messages, REST will be more efficient. However, if you’re handling large message — some of our services takes multi-KB-sized messages in and produce multi-MB-sized responses — then in either case, the overhead will be dwarfed by the message content.

“For example the way the PHP SoapServer class handles arrays of data is (or was last time I checked) incompatible with the way an ASP.NET SOAP client handles them.”

This is a much more serious misconception as it confuses the messaging protocol (SOAP) with the databinding layer (aka marshalling/unmarshalling) which is responsible for mediating between language-native data structures and XML.

Any decent SOAP toolkit should give you the option to receive the whole request as XML, and/or generate raw XML for the response yourself. Databinding is not part of the SOAP spec.

At their heart, SOAP messages are also just XML documents, exactly like REST, and there’s always the option of parsing the XML yourself, exactly as you would with REST. We do this extensively, for performance reasons. It can also be useful, as your article suggests, for sidestepping compatibility issues — because every language can read/write XML.

You can even use SOAP to send/receive arbitrary non-XML data, e.g. via attachments or CDATA or large strings… e.g. plain text, JSON etc.

One final note — certainly in the Java world, many toolkits (e.g. CXF) offer both SOAP and REST access to the same operations, with minimal extra work. I don’t know how common this is in other languages.

Hope this clarifies a couple of things — looking forward to the next in the series.