SOAP
API - Application Programming Interface
2 min read
This section is 2 min read, full guide is 16 min read
Published Sep 24 2025
8
Show sections list
0
Log in to enable the "Like" button
0
Guide comments
0
Log in to enable the "Save" button
Respond to this guide
Guide Sections
Guide Comments
API
SOAP is a protocol for exchanging structured information in web services. It uses XML as the message format and typically runs over HTTP, but can also use other protocols like SMTP or TCP.
SOAP is not dead, but it’s largely considered legacy. Most new projects avoid it unless strict enterprise standards or backward compatibility demand it.
Key Features
- XML-based → Messages are always in XML, making them verbose but highly structured.
- Protocol, not just style → Unlike REST (an architectural style), SOAP is a formal protocol with strict rules.
- WSDL (Web Services Description Language) → Services are defined using WSDL files, which describe available operations, inputs, and outputs.
- Transport-agnostic → Usually runs on HTTP, but can also work over SMTP, JMS, TCP, etc.
- Security & Reliability → Built-in standards for encryption, authentication, and transaction handling (WS-Security, WS-ReliableMessaging).
How It Works
- The client sends a SOAP request (an XML envelope with headers and a body).
- The server processes it and sends back a SOAP response (also XML).
- Both sides rely on the WSDL contract to know how to communicate.
Advantages
- Strong standards & security (ideal for sensitive industries).
- Formal contracts (WSDL ensures strict client–server agreement).
- Protocol independence (not tied to HTTP).
- Good for complex enterprise apps (supports transactions, ACID compliance).
Disadvantages
- Verbose & heavy (XML adds overhead).
- Slower performance compared to REST/gRPC.
- Steeper learning curve for developers.
- Less flexible for modern web/mobile apps.
Common Use Cases
- Banking & financial systems.
- Government & enterprise applications.
- Legacy systems where strict standards are required.
- Systems needing guaranteed delivery and strong security.
Security
- SOAP often uses WS-Security standards:
- UsernameToken → Includes username/password inside the XML header.
- X.509 certificates → Public-key cryptography for message signing/encryption.
- SAML tokens → Federated authentication for enterprise apps.
- Security is built into the message, rather than relying solely on transport (HTTP).
SOAP Request Example
POST /UserService HTTP/1.1
Host: example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://example.com/GetUser"
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:usr="http://example.com/user">
<soapenv:Header/>
<soapenv:Body>
<usr:GetUserRequest>
<usr:UserId>123</usr:UserId>
</usr:GetUserRequest>
</soapenv:Body>
</soapenv:Envelope>
Explanation:
<Envelope>
→ The root of the SOAP message.<Header>
→ Optional metadata (like authentication tokens).<Body>
→ The actual payload of the request.- Namespaces (
xmlns
) define the XML schema.
SOAP Response Example
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:usr="http://example.com/user">
<soapenv:Header/>
<soapenv:Body>
<usr:GetUserResponse>
<usr:User>
<usr:Id>123</usr:Id>
<usr:Name>Alice</usr:Name>
<usr:Email>alice@example.com</usr:Email>
</usr:User>
</usr:GetUserResponse>
</soapenv:Body>
</soapenv:Envelope>
Explanation:
<GetUserResponse>
→ Wraps the returned data.<User>
→ The actual user object.- Nested XML elements correspond to the fields of the object.