Why SOAP Lost

SOAP-Simple Object Access Protocol-was anything but simple. It was a specification for remote procedure calls over HTTP using XML, backed by a stack of standards designed to handle every enterprise integration concern imaginable. By the mid-2000s it had become the default choice for web services. By 2010 it was losing ground to REST everywhere it was not already entrenched.

Understanding why requires looking at what it promised and what it actually cost.

What SOAP Promised

SOAP’s value proposition was formal interoperability. Any two systems that implemented the specification correctly could communicate regardless of language, platform, or vendor. The contract was machine-readable and enforceable. Tooling could generate client and server code from a WSDL document. Enterprises could build integrations that were typed, documented, and verifiable.

For organizations integrating systems across vendor and language boundaries-banks, insurers, large manufacturers-this sounded like a solution to real problems. And in some cases, it was.

The XML Tax

Every SOAP message is wrapped in an XML envelope:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetUser>
      <userId>42</userId>
    </GetUser>
  </soap:Body>
</soap:Envelope>

For a request carrying one integer, this is significant overhead. The XML serialization and deserialization cost was non-trivial at scale. Payloads were large relative to their information content. Networks were slower, and bandwidth was more expensive than it is now-the verbosity mattered.

JSON over REST typically carries the same data in a fraction of the bytes. The difference is not just network cost. XML parsing is slower than JSON parsing. The cumulative effect across millions of requests is measurable.

WSDL Complexity

Web Services Description Language described a SOAP service: its operations, message formats, data types, and endpoint address. A WSDL file was supposed to be the complete specification.

In practice, WSDL files became some of the most difficult documents in a codebase to read and modify by hand. The schema was verbose, deeply nested, and required understanding of XML Schema (XSD) to interpret. Generated client stubs often abstracted the complexity-until the abstraction broke or the WSDL changed in a way the code generator did not handle cleanly.

The tooling dependency became a liability. Teams that needed to debug at the protocol level could not easily reason about what was on the wire without specialized tools.

The WS-* Standards Explosion

SOAP was extensible through a family of additional specifications collectively called WS-*. These addressed real concerns:

• WS-Security: message-level encryption and signing
• WS-ReliableMessaging: guaranteed delivery
• WS-Transaction: distributed transaction coordination
• WS-Addressing: endpoint references and message routing
• WS-Federation, WS-Trust, WS-Policy…

Each specification had independent versioning. Interoperability between implementations of the same specification was inconsistent. A WS-Security implementation from one vendor did not always work correctly with another. Testing cross-vendor compliance required significant effort.

The standards were addressing genuine enterprise requirements. But the complexity of implementing, testing, and maintaining WS-* compliance consumed engineering time that could have gone elsewhere.

REST as a Correction

REST did not defeat SOAP on features. It offered a simpler mental model: resources identified by URLs, operations expressed through HTTP verbs, representations in JSON or XML. No separate description language required. The API surface was navigable in a browser.

For most web integrations, the formal guarantees of SOAP were unnecessary. Public APIs-payments, maps, social platforms-did not need distributed transactions or message-level signing. They needed to be easy to call from any language without generating code from a schema document.

REST won because it matched the actual requirements of most web integrations. SOAP remained the appropriate choice for the subset of integrations that genuinely needed its guarantees.

What SOAP Got Right

The formal contract was a real contribution. Knowing exactly what a service accepts and returns, in a machine-readable format, with versioning and type information, is valuable. The tooling that could generate clients from that contract reduced integration effort.

OpenAPI (formerly Swagger) carries this idea forward for REST. gRPC carries it forward for RPC with Protocol Buffers. The lesson was not that contracts are bad-it was that the contract format and the protocol layer were more complicated than the value justified for most use cases.

The successor protocols kept the principle and discarded the overhead.