What is SOAP? A Modern Tester's Guide to a Still-Alive Protocol

SOAP in one sentence

SOAP (Simple Object Access Protocol) is an XML-based messaging protocol where every request and response is wrapped in a strict, schema-validated XML envelope — typically sent over HTTP POST.

Created by Microsoft in 1998. Peaked in the mid-2000s. Declared dead many times since. Still quietly runs trillions of dollars of payments, insurance claims, shipping manifests, and government filings.

Why SOAP still matters in 2026

If you work in:

• Banking and payments — SWIFT, card networks, core banking systems
• Insurance — policy administration, claims clearing, reinsurance
• Government and healthcare — tax filing, electronic health records, HL7
• Logistics — shipping manifests, customs declarations
• Enterprise software integrations — SAP, Oracle, older Salesforce APIs

…you will meet SOAP. It's not going away because the cost of replacing battle-tested XML integrations is higher than the cost of keeping them.

The envelope

Every SOAP message is an envelope:

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <!-- optional: auth tokens, routing info -->
  </soap:Header>
  <soap:Body>
    <GetUser xmlns="http://demo.totalshiftleft.ai/users">
      <Id>1</Id>
    </GetUser>
  </soap:Body>
</soap:Envelope>

Three parts:

• Envelope — the root wrapper. Always there.
• Header — optional metadata: auth tokens (WS-Security), transaction IDs, routing hints.
• Body — the actual operation and its parameters.

Try it live

curl -X POST 'https://demo.totalshiftleft.ai/soap' \
  -H 'Content-Type: application/json' \
  -d '"<?xml version=\"1.0\"?><soap:Envelope xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"><soap:Body><GetUser xmlns=\"http://demo.totalshiftleft.ai/users\"><Id>1</Id></GetUser></soap:Body></soap:Envelope>"'

The response comes back as another XML envelope with a <GetUserResponse> element inside <soap:Body>. No JSON. No optional fields. Everything the schema says should be there, is there.

Contracts are strict

Unlike REST, which is a loose style, SOAP is a tightly specified protocol:

• WSDL — every SOAP service publishes a WSDL (Web Services Description Language) document: a machine-readable contract describing every operation, every input type, every output type, and every fault.
• XSD — inside the WSDL, XML Schema Definitions nail down exact types, ranges, required/optional fields, enumerations.
• SOAP Faults — standardized error envelope. Every SOAP error looks the same.

The upside: you can generate client code, server stubs, mocks, and full test suites from the WSDL alone. The downside: changing the contract is expensive, because every consumer needs regeneration.

SOAP vs REST at a glance

SOAP is not "old REST." They're different tools. SOAP is a protocol for message exchange with strict contracts. REST is an architectural style for resource-based HTTP APIs.

What SOAP does well

1. Strict contracts — every field typed, validated, and enforced. No "oops, that field was a string last week, integer now."
2. Built-in security standards — WS-Security, WS-Trust, WS-ReliableMessaging are mature, interoperable standards banks have audited for 20 years.
3. Transport-agnostic — a SOAP message can travel over HTTP, SMTP, or message queues. REST is HTTP-only.
4. Tooling for contract-first development — WSDL → generated clients in any language, for free.

What SOAP does poorly

1. Verbose — XML envelopes are huge compared to JSON bodies. Bandwidth and parsing costs add up.
2. Not browser-friendly — JavaScript can technically do SOAP, but nobody enjoys it.
3. Slower tooling iteration — SOAP ecosystems evolve at enterprise pace. REST tooling ships weekly.
4. Caching — POST-based, with body-dependent responses, so HTTP caches don't help.
5. Learning curve — namespaces, envelopes, WSDLs, XSDs, SOAP Faults, WS-* standards — a lot to learn just to make one call.

What a tester needs to know

Testing SOAP looks superficially like testing REST: send a request, assert on the response. The differences:

• Assertions are XPath-based, not JSON-path. //user/email/text() instead of $.user.email.
• Validate against the XSD, not just sample data. A response that's "correct" shape-wise but wrong type is a real bug.
• Test SOAP Faults explicitly. Unlike HTTP status codes, SOAP Faults have structured fault codes (soap:Client, soap:Server) and fault strings.
• Generate from WSDL, never hand-craft envelopes. Tooling does it better and keeps up with contract changes.

The SOAP testing guide dives into all of this in detail.

What's next

Next: WSDL explained — the contract document that's the secret to sane SOAP testing. If you understand WSDL, SOAP becomes manageable.