Business value of REST vs. SOAP

Those of you that have had the pleasure (or pain) of interacting with me in-person on this topic know that I can pine for the good ole days of SOAP. I first used SOAP around 2002, as part of a registration system for a Student Government conference at Texas A&M University. The system was PHP and we needed to interact with a .NET based payment processor and SOAP was how it was done. It was incredible see it all happen over HTTP.

As the 2000’s went on, the tooling around SOAP, WSDLs, and code generation from WSDLs matured across a wide variety of languages. For the most part, I think the tooling worked out of the box, in part because the WSDL and XSD standards were quite specific. Secondly, even though then and now, a lot of poor quality services and integrations are built, most teams adopted those tools. The only time I really saw SOAP get annoying was when features at the complex margins (like WS-Policy) were used but they were relatively rare.

As someone that grew up in this world, it came as a shock to me when the 2010’s rolled around and I was told SOAP was “too complex” and we needed something new (or old), REST. While I do not necessarily think REST is terrible, I think it suffers from a few shortcomings that SOAP did not have, nor do I think it really changes the value to the business much over SOAP.

Resistance to schemas from the start

REST from my view seemed like an anarchist’s approach to software integration. The need for a schema language of any kind was often discarded with statement like “if you want to know what the resource looks like, just do a GET.” Of course this ignores all the permutations not covered by that one example.

Eventually, standards like RAML and Swagger/OAS did appear but in my experience, the REST world has been slow to adopt them or when they do, they often do not document a lot of their resources.

Straw man arguments against SOAP

My favorite involves JSON being easier to read and write. There may be some credence to the idea that JSON is easier to read. In terms of writing XML or JSON, I’ve never written either. In both JSON and XML’s case, it’s a serialization format and I’m relying on frameworks and my code to read and write the language. It was not at the top of my list. Usually what made SOAP services hard to read was poorly defined services, which of course can also occur with REST resources.

Lack of code generation and other tools

It is true that REST became more popular during an era of dynamic languages that made the role/value of serialization/code generation less clear. That said, in part due to the reticence to adapt schemas and standards like Swagger or RAML, the REST world has often lagged behind with code generation and tooling. That tooling has a real impact when it comes to ease of development via syntax completion and also the testing benefits that can result from using code generation/compilation/runtime errors to detect contract deviance.

Achilles heel of HTTP Verbs

SOAP, because it did not define verbs for you, forced you to identify what your operations were. I kind of wonder if sometimes it forced us to be more deliberate about what operations a system should expose, rather than just making a bunch of data available for a GET. Did SOAP encourage us to make better decision decisions with service encapsulation? I’m not sure but to be fair, you can do this just fine in REST. You just have to be more thoughtful about what your resources are and keep an eye on ‘abuse’ of deriving too many things based off checking fields that should be encapsulated in GETs for state changes.

Where do we go from here?

Have REST integrations really added more business value than SOAP services did? How would the “API craze” of the 2010’s have turned out if it was SOAP driven rather than REST driven? I’m not sure. What I can say though is some of the benefits of SOAP, if pushed aside, show up in tech debt outside of our REST integrations. We should think about that before rushing to adopt new technologies and look for the business value of making the switch rather than just shiny objects.