SOAP Overview

Simple Object Access Protocol. XML-based RPC protocol from Microsoft (1998). At its peak (2003–2010), SOAP was the “enterprise standard” for web services. REST mostly replaced it for public APIs; SOAP remains in legacy enterprise systems.

For new APIs: don’t choose SOAP. For integrating with existing SOAP services: you’ll need to know enough.

What SOAP is

• A message format (XML envelope with header + body).
• A protocol binding (usually HTTP, but also SMTP, JMS, raw TCP).
• A contract format (WSDL — Web Services Description Language).
• A family of extensions (WS-*: WS-Security, WS-ReliableMessaging, WS-Transaction, …).

The “WS-*” stack is what makes SOAP feel “enterprisey.” Each extension adds capabilities (signing, encryption, transactions, reliable delivery) at the cost of complexity.

A SOAP request and response

Request:

POST /UserService HTTP/1.1
Host: api.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "https://example.com/UserService/GetUser"

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <wsse:Security xmlns:wsse="http://...wsse-1.0">
      <wsse:UsernameToken>
        <wsse:Username>alice</wsse:Username>
        <wsse:Password>secret</wsse:Password>
      </wsse:UsernameToken>
    </wsse:Security>
  </soap:Header>
  <soap:Body>
    <GetUser xmlns="https://example.com/UserService">
      <Id>42</Id>
    </GetUser>
  </soap:Body>
</soap:Envelope>

Response:

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetUserResponse xmlns="https://example.com/UserService">
      <User>
        <Id>42</Id>
        <Name>Alice</Name>
        <Email>alice@example.com</Email>
      </User>
    </GetUserResponse>
  </soap:Body>
</soap:Envelope>

Always POST. Always XML. Same URL for every operation (the operation is in SOAPAction header and the body element name).

SOAP vs REST in one paragraph

REST won for ~95% of new APIs because it’s lighter, browser-friendly, and JSON is easier than XML. SOAP retains advantages in:

• Strict contracts (WSDL enforces them tightly).
• Built-in security and transactions (WS-Security, WS-AT).
• Transport-agnostic (SOAP over message queues for guaranteed delivery).

For most internal APIs, those advantages aren’t worth the complexity.

The good parts of SOAP

• Tight contracts via WSDL — codegen for clients in any language, with strict type checking.
• Built-in fault model — soap:Fault is the standard error response shape.
• Mature tooling for enterprise — banks, insurers, telcos have decades of SOAP infrastructure.
• Transport-agnostic — same protocol over HTTP, SMTP, JMS, etc.
• Security via WS-Security — message-level signing/encryption (not just channel-level TLS).
• Reliable messaging — guaranteed delivery via WS-ReliableMessaging.

The bad parts

• XML verbosity — payloads 5–10× larger than equivalent JSON.
• Parsing cost — XML parsing is slow vs JSON.
• Complexity — WS-* specs are dense; gotchas in canonicalization, namespaces, MTOM/XOP encoding.
• Tooling rot — many SOAP libraries are abandoned or barely maintained.
• No native browser support — JS can do it but it’s pain.
• Security pitfalls — XML signature wrapping (XSW), XXE (XML External Entity) attacks.

SOAP-style RPC

SOAP is RPC: “call this method with these arguments.” Operations have names; bodies are typed; no concept of “resources” or HTTP verbs.

GetUser(id) → User
CreateUser(name, email) → User
UpdateUser(id, name, email) → User
DeleteUser(id) → boolean

Each operation has a name. The HTTP verb is always POST. The URL doesn’t change.

vs REST:

GET /users/42
POST /users
PUT /users/42
DELETE /users/42

Resource-shaped URLs, semantic HTTP verbs.

Versioning

SOAP services version via:

• Namespace versioning — xmlns="https://example.com/v2/UserService".
• WSDL versioning — publish UserService.wsdl and UserServiceV2.wsdl.
• Endpoint versioning — /v1/UserService, /v2/UserService.

Like REST, breaking changes mean a new version; non-breaking adds elements (XSD allows extension).

When you’ll deal with SOAP

You’re consuming an existing SOAP service when:

1. Integrating with a bank or payment processor — SWIFT, ACH systems, older payment gateways.
2. Government / public-sector — tax filing, customs, court systems.
3. Healthcare — HL7v3, some HIE (Health Information Exchange) systems use SOAP.
4. Telecom — provisioning, billing systems.
5. Old enterprise systems — SAP, PeopleSoft, Oracle E-Business Suite, sometimes Salesforce older APIs.

You’re rarely building a new SOAP service. If you are, it’s usually because a partner mandates it.

See 05_when_youll_see_soap.md.

Performance ballpark

For a typical “get user” call:

SOAP is the slowest of the bunch. For most apps the difference doesn’t matter; for high-throughput, it does.

Common interview confusions

• “SOAP is dead.” — for new APIs basically yes. For existing enterprise integrations, very alive.
• “SOAP and REST do the same thing differently.” — close, but SOAP is RPC; REST is resource-oriented. Different mental models.
• “SOAP requires HTTP.” — works over HTTP usually, but spec is transport-agnostic. SMTP, JMS, raw TCP all possible.

Interview angle

• “What is SOAP?” — XML-based RPC protocol from Microsoft (1998). Messages are XML envelopes (<soap:Envelope> with optional <Header> and <Body>). Contract via WSDL. Family of WS-* extensions for security, reliability, transactions.
• “Why did REST win over SOAP?” — simpler (HTTP verbs + JSON vs XML envelopes + WS-* specs), browser-friendly, smaller payloads, less tooling overhead. SOAP’s strengths (strict contracts, message-level security) matter less for typical web APIs.
• “When would you still use SOAP today?” — integrating with existing enterprise systems that already speak SOAP (banking, government, telecom, healthcare). Don’t choose SOAP for new APIs.
• “What’s a WSDL?” — Web Services Description Language; an XML document describing a SOAP service: types (XSD), operations, bindings (which transport), endpoints. Equivalent of OpenAPI / .proto for SOAP.
• “SOAP vs REST for a new internal API?” — REST. SOAP’s overhead and tooling rot make it a bad default. Pick SOAP only if mandated by integration requirements.
• “What’s the SOAPAction header?” — HTTP header identifying which operation the message invokes (since the URL doesn’t differentiate operations). Some services require it; some ignore.