SOAP is a protocol from the late 1990s for exchanging XML messages over HTTP (or anything else). It's heavy by today's standards, but its strict contracts and built-in security made it the default in regulated industries — and you'll still meet it integrating with banks, payment networks, governments, telcos, and old SAP/Oracle systems. You don't choose SOAP; SOAP chooses you.
← Back to APIs & Networking<Envelope> with a <Header> (auth, addressing, transactions) and a <Body> (the actual payload or fault).WSDL is a strongly-typed, machine-readable contract. Generate clients in any language; the wire shape and types are guaranteed to match. This is the same idea gRPC and OpenAPI deliver today — SOAP did it 20 years earlier, just with a lot more XML.
WS-Security signs and encrypts parts of the message (not just the transport), so a SOAP envelope can pass through intermediaries without losing its integrity guarantees. Banks, governments, and healthcare systems lean on this — the message is signed end-to-end regardless of how many hops it makes.
WS-ReliableMessaging delivers exactly-once even over flaky transports. WS-AtomicTransaction coordinates distributed transactions across SOAP services. Heavy machinery, but it's there if your industry's compliance requires it.
The same payload that's 100 bytes of JSON is a kilobyte of XML with namespaces and envelopes. CPU cost to parse, network cost to ship, human cost to read — all higher.
You can't curl a SOAP service meaningfully. You parse a WSDL, generate stubs, compile, run. The "open a browser, hit the URL, see JSON" workflow doesn't exist. Productivity in modern IDEs depends on plugins; in scripting languages it's outright painful.
The standards stack tried to solve every distributed-systems problem at the protocol layer. The result was an enormous spec surface where no two implementations agreed on every corner. The pendulum swung to "do less at the protocol layer, push concerns to the app" — REST, then gRPC.
SOAP doesn't fit the web. Calling a SOAP service from JavaScript is awkward; XML is verbose to construct; CORS and security headers were never designed with SOAP in mind. As browsers became the dominant API client, SOAP's relevance faded.
wsimport (Java), svcutil (.NET), zeep (Python), or node-soap.You don't, anymore — for new APIs, REST or gRPC are the right call. SOAP comes up only when you're integrating with a partner who already speaks it. When that happens, accept the contract, generate the client, build a clean adapter, and don't fight the protocol.