REST vs. SOAP – SOAP’s Revenge

REST vs. SOAP – SOAP’s Revenge

The year was 1999, the internet was blooming, Simple Object Access Protocol (SOAP) burst onto the scene, based on the latest and greatest dev: XML. SOAP had its 15 minutes of fame, but was very verbose and prescriptive and often required tooling to use it efficiently. A whole family of web service specifications (WS-*) grew on top of SOAP and it was used successfully for interoperability.

The relatively heavy weight of the SOAP protocol didn’t sit well with the nimble web developers of the time. Representational State Transfer (REST) was just the thing – simple to describe, very flexible and almost directly mapped to HTTP. No need for special libraries to consume.

Fast forward to 2015 and you see a plethora of REST best practices, how to validate your content (JSON schema), how to authenticate, how to report errors, how to implement stateful interactions, etc. Everyone and their cousin has their own flavor. What do you put in the HTTP headers, what do you send as URL parameters and what is in the request body? HATEOAS or not HATEOAS?

These days, every Enterprise/best practice REST API is a proprietary and non-standard half implementation of SOAP. The SOAPjr project attempts to combine the simple parts of SOAP with JSON-RPC to create a clean and yet structured web API protocol. It will be interesting to see how future web APIs are going to be implemented.


About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist