SOAP is the older generation of web services that the modern web API economy grew up defining itself against — the heavyweight, enterprise, standards-laden approach to machine-to-machine communication that REST and the simpler web API model ultimately displaced. To understand the history of APIs, you have to understand SOAP, because SOAP was what came before, and the entire ethos of the web API movement — simplicity over ceremony, HTTP over elaborate envelopes, pragmatism over comprehensive standards — was forged in reaction to the complexity of the SOAP and WS-* world. SOAP didn’t vanish; it persists in enterprises and legacy integrations to this day. But the center of gravity moved decisively away from it, and the story of that move is the story of how APIs became the accessible, web-native thing we know rather than the enterprise-architecture discipline they might have remained.
SOAP’s origins and design tell you why it eventually lost ground, and I covered the technology directly in the early days. I wrote in 2011 about the SOAP technology itself — the protocol designed in the late 1990s, built around XML envelopes, formalized through WSDL service descriptions, and surrounded by the sprawling WS-* family of standards for security, transactions, and reliability. SOAP was thorough, formal, and built for the enterprise: strongly typed, contract-first, tooling-heavy, and designed to handle the rigorous requirements of large-scale enterprise integration. That thoroughness was its strength and its weakness. It could express complex, formal contracts and handle demanding enterprise requirements, but it was heavy, verbose, and required substantial tooling and expertise to work with. For the open web, where developers wanted to make a simple call and get a simple response, SOAP was overkill — and that gap is where REST walked in.
The REST-versus-SOAP transition is the central drama of early API history, and I documented it as it unfolded. I wrote about REST as the technology alternative, and the contrast was stark: where SOAP wrapped everything in XML envelopes and formal contracts, REST used plain HTTP, simple URLs, and whatever data format was convenient — increasingly JSON rather than XML. The web API economy I described in those early years was built on the REST model precisely because it was accessible: a developer could understand a RESTful API in minutes and start making calls, whereas SOAP demanded learning WSDL, generating client stubs, and navigating the WS-* maze. The enterprise embracing web APIs, which I wrote about in 2012, captured the moment when even enterprises — SOAP’s home turf — began moving toward the simpler web API model, recognizing that the accessibility and developer-friendliness of REST outweighed SOAP’s formal rigor for most use cases. A telling marker came in 2011 when Amazon killed its Alexa SOAP API over security concerns, one of many signals that the SOAP era was giving way.
The “we’ve done this before” theme is where SOAP becomes a lesson rather than just a predecessor, and it’s one I returned to repeatedly. I wrote in 2015 that with SOA and APIs, we’d already done this before — because the API world kept reinventing things the SOAP and SOA era had already grappled with, often without learning from that history. WSDL was the machine-readable service description before Swagger and OpenAPI; the SOA governance discipline anticipated API governance; the WS-* standards tackled security and reliability problems that REST-based APIs later had to solve again. I wrote about seeing reflections from the past rippling in the API pool when translating WSDL to OpenAPI, and about how when you believe everything in tech is new and nothing repeats itself, you’re setting yourself up to repeat old mistakes. SOAP and the SOA era weren’t just a discarded predecessor; they were a previous iteration of the same fundamental problems, and the API world’s tendency to dismiss them as obsolete meant repeatedly relearning lessons that generation had already paid for.
SOAP’s persistence and the maturing recognition that APIs are not just REST round out the history, and I made a point of this. I wrote in 2018 that APIs are not just REST — because the dismissive “SOAP is dead, REST won” narrative oversimplifies a more complex reality. SOAP never disappeared; it remains embedded in enterprises, in financial services, in healthcare, in government, and in countless legacy systems that still run on it. The mature view recognizes that the API toolbox includes many styles — REST, SOAP, GraphQL, gRPC, event-driven, and more — each suited to different needs, and that SOAP’s strengths in formal contracts and enterprise rigor still matter in the contexts that demand them. The triumphalist REST-killed-SOAP story is too simple; the truer story is that REST opened APIs to the web and the masses while SOAP retreated to the enterprise contexts where its formality remained valuable. Both still exist, serving different needs.
Where I land on SOAP is that it’s the essential historical context for understanding why the web API economy looks the way it does — and that treating it as merely obsolete is both inaccurate and a mistake. The web API movement defined itself against SOAP’s complexity, and that reaction shaped everything that followed: the preference for simplicity, the embrace of HTTP and JSON, the developer-first ethos, the suspicion of heavyweight standards. But SOAP also solved real problems that the API world later had to solve again, anticipated disciplines like governance and machine-readable description that we treat as new, and persists in the enterprise contexts where its rigor remains valuable. The honest history holds all of this: SOAP was the older generation that the web API economy grew up rejecting, and that rejection produced something genuinely more accessible and more successful — but the rejection was never as total or as wise as the triumphalist narrative claims. Understanding SOAP, and respecting what it got right alongside what it got wrong, is part of understanding APIs as a continuous history rather than a series of clean breaks with a forgettable past.
References
- The API Economy
- API Technology: REST
- API Technology: SOAP
- Amazon Kills Alexa SOAP API Due To Security
- Some Thoughts For The Enterprise Embracing Web APIs
- Here We Go Again: SOA And API, We Have Already Done This
- When You Believe Everything In Tech Is New And Nothing Repeats Itself
- Seeing Reflections From The Past Rippling In The API Pool When Translating WSDL To OpenAPI
- API Is Not Just REST
