One of the things in life I really regret is suggesting SOAP on a project. I thought it was just a packaged, somewhat elaborated version of a semi-reasonable XML-RPC type thing --- and worse, that the idea that it was standardized meant that you could count on some kind of half-decent interoperability.<p>It was initially sold that way, but that was just the first of a parade of sales pitches, hilariously chronicled here, <a href="http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/" rel="nofollow">http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-...</a> --- endlessly shifting as if seen through a fun-house mirror.
SOAP is a nightmare.<p>soapUI is an application that will let you fiddle around until you get the calls right.<p>I recently did exactly this. I wound up not only generating the SOAP envelope by hand but also the HTTP headers:<p>SOAPAction: "<a href="http://...//SubmitDataform" rel="nofollow">http://...//SubmitDataform</a><p>What is the action I am trying to do doing in the HTTP headers?
Debugging SOAP stuff is a complete nightmare, but trying to figure out and implement somebody's RESTful API that has 100 different types of objects is also a hassle, since there isn't code generation that can help you.<p>For tiny one-API-call tasks, I'd much rather use a JSON REST API that I completely understand. When I'm trying to interface with a complicated system that has a million different objects, I'd rather spend an hour figuring out the tools, then rely on generated code so I can take advantage of IDE auto-completion instead of digging through the documentation to remember the params and return value. It's the in-between of these two cases that's the devil, especially since big nasty APIs always start out small and simple.
Urgh. I had exactly this experience trying to get the Exchange Web Services API to work. That's worse, because the author's solution, dropping any pretense at using a notionally "pluggable" API and just debugging with Wireshark, won't fly over HTTPS.
Not that I'm a big SOAP fan, but the author seems to be seriously confused:<p><i>"For starters you have to point Visual Studio (sigh) to the service reference, at which point nine thousand (yes, that’s nine-zero-zero-zero) lines of code are generated."</i><p><i>"Not a descriptive error, or an HTTP status code, or anything that could be used to track down the problem but a “SOAP Error.”"</i><p><i>"Long story short, in order to inspect SOAP messages you have to write a class that implements the ICLientMessageInspector interface."</i><p>These are supposed to be problems with SOAP? To me they look like a crappy implementation.<p>The conclusion is also crappy:<p>"In my mind SOAP’s biggest failure is what some people consider to be its biggest success – it abstracts away all notion of the underlying HTTP model and replaces it with crutches like code generation."<p>Jeez, man - SOAP has problems, but <i>code generation</i>!? It's not a problem with SOAP but with the way your environment integrates with SOAP. Code generation over <i>any</i> protocol would create the same problems and there's nothing about SOAP that makes code gen inevitable.
I have to say, REST is just a lot more straightforward than SOAP. Although there are numerous advantages with SOAP, I always cry myself to sleep at night when I find out that I have to use a SOAP API to complete a part of a project.
Actually the guy is actually complaining about consuming a WS from WCF (important distinction because consuming it using the default WS stack from .NET is a much better experience).
Besides that...carry on praising REST.
It was just a bad SOAP api. You can write a bad and cumbersome REST api as well if you want, and MS would certainly be capable of doing so. SOAP is not really the problem here.
To give a slightly different spin to the discussion: does REST solve some of the problems SOAP addresses? First there was REST, now closely related to HATEOAS... I see the acronyms are coming.<p>How to discover the meaning of data in the absence of a WSDL/RESTDL? Will we have microformats with links pointing to ontology-servers? Wat if its JSON?<p>I wonder what REST looks like five years from now, when for instance, IBM and M$ become involved in a standardization process ...
I don't like Soap for the same reasons everyone hates it.
Having said that, in the Java space there are plenty of tools that turn the Soap experience into a bearable one.
With CXF, for instance, is quite trivial to generate client code out of a WSDL file. The generator binds the request/response payload to Java beans so the developer doesn't have to understand the intricacies of the protocol.
Debugging is also simple.
Diss on SOAP if you want but it does provide good error support for working with transactions in Java EE 6, ESB, etc. If you need to use infrastructure that works with SOAP, then use SOAP and stop whining.<p>If you don't need to interop with existing systems that use SOAP, then sure, a REST style makes sense.
SOAP in visual studio might be a pain, but its really not that difficult when working in PHP:<p><a href="http://php.net/manual/en/book.soap.php" rel="nofollow">http://php.net/manual/en/book.soap.php</a><p>I've implemented both servers and clients using SOAP with low to no hassles.<p><pre><code> Bad implementation != bad spec</code></pre>
edit: appears to be back and working fine.<p>Embarrassing - despite my best efforts it appears as if my little linode couldn't handle being frontpaged - here's a cached entry for now:<p><a href="http://webcache.googleusercontent.com/search?q=cache:UehgGNUoeqUJ:thecoffman.com/2011/01/please-drop-the-soap/+http://thecoffman.com/2011/01/please-drop-the-soap/&cd=1&hl=en&ct=clnk&gl=us&source=www.google.com" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:UehgGNU...</a><p>The blog entry is cached as a static page hourly and served via nginx as such - this load shouldn't have killed it. Will be interesting to dive into.