Mark Baker is upset because SOAP permits usages which are not, in his and many people’s opinion, well architected. Usages such as RPC. While many of Mark’s arguments resonate with me, he tends to throw the baby out with the bathwater. He might as well say that Python is not a good language for building REST systems because it can also be used for RPC.
I realize my position is far from typical, and appears inconsistent at times, but I thought I’d been pretty clear about it at least. Oh well. Ok, so let me get it all out, and describe what I believe – and what I don’t – about REST and SOAP;
I believe SOAP is a valuable and useful technology.
I believe the Web, and in particular the subset that follows the constraints of the REST architectural style, is a fundamental breakthrough in the evolution of large scale distributed systems, that will continue to effect how most systems, both human and machine-targetted, are built for the foreseeable future.
I believe SOAP can provide value outside the constraints of REST, but I also believe that its predominant value, by far, is when used within the constraints of REST.
I believe that using SOAP within the constraints of REST does not mean that HTTP (or Waka) has to be used.
I believe that using SOAP as a means for extending underlying application protocols, is the most valuable thing it can be used for.
I believe that using SOAP as a framework from which to build new application protocols has some value, so long as those new protocols are built on transport protocols and not tunneled over other application protocols.
I believe SOAP will fail to see significant use on the Internet because the predominant use of SOAP today is to tunnel new application protocols over existing application protocols, and to encourage an explosion in per-service application protocols, not a unification of application protocols as REST does via generalization.
P.S. I’ll believe it when I see it. 8-)
no comment until now