I think this is largely accurate, but one thing the article misses is that SOAP was never as interoperable as it was claimed to be. If you had a Microsoft client and a Microsoft server, things would work great, but as soon as you started mixing vendor implementations, you quickly ended up in configuration hell. For simple SOAP messaging you could usually get it to work with enough elbow grease, but for any of the WS-* protocols you might as well be doomed. I lost days, if not weeks, of work to failed interop of WS-Security across two different vendors (both Java, and both with the code under my control).
The S Stands for Simple — <a href="https://web.archive.org/web/20140710041718/http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/" rel="nofollow">https://web.archive.org/web/20140710041718/http://wanderingb...</a><p>a web classic, can never be linked enough times
The entire thing hide itself behind a "don't worry about how that works, the tools and libs are supposed to do that for you" philosophy, and then those would fail and break so often it was almost comical. You would then end up debugging the entrails of a SOAP exchange, which is one of the most terrible things I've seen.
I feel like I spend a troubling amount of time as a software developer dealing with and/or avoiding solutions that are much more complicated than the problems they're trying to solve.
The fact that SOAP is not reasonably supported in a browser was a huge reason it fell down. When SOAP first came on the scene, complicated AJAX based applications were not typical. But as more and more JSON/HTTP APIs emerged in conjunction with browsers becoming more powerful and rich apps build built in them, the meaninglessness & complexity of SOAP grew.<p>Also, another major issue with SOAP is that most all of the popular tools would generate classes based on a WSDL. This creates a toolchain issue that is readily solved for someone experienced, but can really suck if you are new to the idea of generated code working it's way into your project.<p>Much worse was the scenario of WSDL versioning in conjunction with these tools that generated classes. If the API never broke backwards compatibility, you should be OK and can just use the newer class representations, counting on the service and tools to deal with null fields appropriately (not always true unfortunately). But if version bumps of an API/WSDL broke backwards compatibility... then you had to have separate class hierarchies for different versions of the WSDL; what an intense headache. Contrast that to web REST APIs; without a formal schema and a lack of class-centric tooling, client libraries would often let the author stuff in the params themselves and let the serializer stuff in the body based on the params; so yes your API is not as formal, but this isn't a big issue but offers infinite flexibility in dealing with one-off versioning issues or interop issues.<p>As someone else mentioned, some platforms couldn't interop with others (differences as it related to simply stuff like nullable fields or primitives existed all over; total nightmare), and some features of WSDLs didn't translate well to certain languages.<p>A great WSDL author would know to make their WSDL as simple as possible, because they had spent time working with various language toolchains and new the limitations out there, but that's asking way too much and not realistic for someone to have to spend all their time trying to understand all the ways someone in language XYZ might use their WSDL.
I think SOAP has lost in a sense that it's no longer very popular around many web developers.<p>But has it really lost? I still see it used a lot in large corporate and high tech environments.<p>I was never a big fan of SOAP myself, but that's also partly because when I started, the tooling wasn't great and I got mostly a negative user-experience. But this is many years ago.<p>My understand is that these days it's quite good, and it has a pretty good user-experience. Furthermore, everything is backed by xml schemas, which makes it easier to create and require strictly valid xml being sent back and forward.<p>While some equivalents exist in REST-ish API's, it's arguably not very common and with SOAP it's a pretty much a free and built-in feature that everybody uses.<p>Modern web API design is great for getting things up and running fast, but it's not amazing for rigorously robust design.<p>I don't really like the "SOAP is bloated and over-engineered" narrative. It is uninteresting now, and was uninteresting 10 years ago.<p>I think it's much more interesting to learn about the things that SOAP did get right, and see how we can apply some of these learnings in our API's.
My guess is that more and more people are coming to the realization that xml is great for fluid text and document formatting, but too ambiguous to serve as a data structure format.<p>XML nodes and children are just too slippery. I've actually argued with enterprise developers about why serving the following format was a terrible idea.<p><pre><code> <user>
<id>123456</id>
<name>Joe</name>
<account>Account 1</account>
<account>Account 2</account>
</user></code></pre>
Not sure why the article equates XML with SOAP.<p>Request:<p><pre><code> GET /customers/43456 HTTP/1.1
Host: www.example.org
</code></pre>
Response:<p><pre><code> HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
<customer>Foobar Quux, inc</customer>
</code></pre>
Seems fine to me. In fact, having named elements without the requirement for a dictionary makes parsing straight to an object-representation (without an intermediate property-list) much easier.
In my opinion, WS-* lost not because of the format or verbosity. WS-* lost because the concept is about the continuation of RPC, where you expose custom methods that can be invoked from a client. When state is altered in custom ways, complexity goes through the roof - to the point where you need a DSL (WSDL) to define these methods and how to interact with them.<p>REST simplified things because the concept is about limiting the method invocation to the bare minimum and always have an explicit understanding of the state that is being changed or communicated.<p>The XML/JSON question is not as important as the method/resource question.
“The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well.” – Phil Wadler, POPL 2003<p>SOAP takes XML's problems to the next level.
Hold on to this, <i>"tldr: Simplicity and utility trump large corporate backing."</i><p>When your manager tells you that your API needs to handle something "just in case", when your customer asks, "But what if I want to use this API with mumblefratz?", and when you look at your code and say, "Gee, if I make this a variable I could handle any special edge case by encapsulating its specialness in the variable ..."
Pete Lacey's parody of SOAP is both hilarious and also very accurate:<p><a href="http://harmful.cat-v.org/software/xml/soap/simple" rel="nofollow">http://harmful.cat-v.org/software/xml/soap/simple</a>
I've had the "fortune" to work with SOAP as well (java implementation) and I never could shake the feeling that it was designed with the intention of being obscure. It seems you could employ an entire batch of consultants just to deal with defining, implementing and changing SOAP APIs (kind of a misnomer I know). The whole change from SOAP 1.1 using an ActionHeader to SOAP 1.2 using an action parameter seems downright misleading. Or downloading WSDL files to automatically create Java classes sounds great in theory but now your program has additional obscure classes with <i>very</i> weird syntax and you have to read through numerous reference guides just to know how you can modify the header of an outgoing request. Such a waste of time.
One nice example of how MS really made things more complex with SOAP is the MSN Messenger Protocol (MSNP), which started out quite simple and sane, then got extremely SOAPy in the later versions; compare protocol interactions pre-SOAP:<p><a href="http://msnpiki.msnfanatic.com/index.php/MSNP8:Getting_Details#Example_SYN_Responses" rel="nofollow">http://msnpiki.msnfanatic.com/index.php/MSNP8:Getting_Detail...</a><p>and doing the same thing with the SOAP'd version:<p><a href="http://msnpiki.msnfanatic.com/index.php/MSNP13:Contact_List" rel="nofollow">http://msnpiki.msnfanatic.com/index.php/MSNP13:Contact_List</a>
It's all about who has the power.<p>With JSON, if the data returned by the server doesn't exactly match the documentation, it's the client's problem.<p>With SOAP, if the data returned by the server doesn't exactly match the documentation, the server is broken. The client, reading the WDSL file which documents the API, will report an error and refuse to continue. This means bug reports the server provider cannot make go away by the usual defect-denial techniques.
<a href="http://www.google.com/trends/explore#q=wsdl%2C%20restful&cmpt=q" rel="nofollow">http://www.google.com/trends/explore#q=wsdl%2C%20restful&cmp...</a><p>SOAP is past its peak but far from dead. In the Microsoft ecosystem, SOAP is nearly transparent, except for a bit of fiddling - you publish your WSDL from your definitions, I consume it to generate an API class on my end, and after maybe ten minutes on either side, we don't even think about SOAP again.
It's funny that the joke starts with a dig at CORBA. When I was worked on a CORBA-based system a decade ago, I thought I'd never see something more over-designed. But this whole document-oriented web services thing makes me feel like: <a href="https://screen.yahoo.com/unfrozen-cave-man-lawyer-1-223412426.html" rel="nofollow">https://screen.yahoo.com/unfrozen-cave-man-lawyer-1-22341242...</a>.
Sure, SOAP's complexity is a problem, but the issue with "RESTful" APIs is that they're so loosely defined, almost all the way to the other extreme. Being able to generate code and have a type-checked API, which is as easy to use as any other local API was a very nice feature we've now lost. I wish there were a better compromise.
SOAP Web Services around still frequently used in a lot of large corporations, where technology evolves a little slower and Microsoft products are still very popular.<p>Being a Rails fan myself, I have always enjoyed using HTTP Web Services and interacting with tech companies' Restful APIs so easily.<p>This post provided a clear, side-by-side comparison of the technologies including the historical context of SOAP, which I found really useful and enlightening. If I could give you some Bitcoin for writing it, I would. Have a new Twitter follower instead.<p>It's hard to find succinct, objective technology articles in this day and age. Most reviews I find are either unconstructively biased ("dynamic typing sucks!") or too long and convoluted to be effective.
I always liked XMLRPC. It seemed really simple. At least in Python they simply mapped to function calls and all of the XML stuff was handled for you. It took minutes to get an API set up with that from any program.<p>I never understood why it's out of favor?
I still have to use SOAP more often than I'd like to these days. It's a pain testing and dealing with all the different tools you have to use just to stand up a basic request.<p>A lot of vendors I've worked with will publish REST web services for public data but as soon as any private information needs to be accessed they use SOAP. I don't know if they just don't trust the tools to make REST secure or what but it's disappointing for sure.<p>Also the people who wrote the SOAP code are long gone which makes support for them even more difficult when I'm trying to get bugs fixed. REST server code has not been anywhere as bad to deal with.
SOAP is still common in healthcare as many IHE profiles rely on SOAP for Cross-community document/data exchange. They are a pain to work with if you don't have a toolset that handles it well.
The article lists<p>1) JSON coming up to replace XML as a serialization technology, and<p>2) and Ruby on Rails (etc)<p>I remember even serious pressure from w/i the XML community in the sense of XML-RPC, and the joke that the <i>entire</i> <i>spec</i> for XML-RPC was smaller than the Table of Contents for the SOAP spec. SOAP was tough. It was confusing to use (fwiw, I had the best luck w/ Perls SOAP::Lite) and difficult enough to implement that devs I knew simply abandoned it.
New Finnish gov digital infrastructure is going to built using Estonian X-road (well next year). And yes, its only SOAP, so I guess either Finns are pretty crazy or SOAP is making a comeback. Go figure.
You can't argue that PUT, DELETE, and POST methods are usable in a browser, and once a rest api starts going hogwild with headers, the GET really doesn't work either.<p>The fact REST didn't provide some way for all methods to be invoked in a simple browser was to me a step towards the inaccessibility of SOAP.