We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Api Design Protocols
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Api Design Protocols
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
Before REST, before GraphQL, before , there was SOAP. Simple Object Access Protocol. Built on XML. Strictly typed. Extremely verbose. And for over a decade, it was THE way enterprise systems communicated.
Banks, insurance companies, healthcare systems, government agencies. They built their entire service infrastructure on SOAP. And much of it still runs today. SWIFT, the network that moves trillions of dollars between banks daily, uses SOAP. HL7 FHIR, the healthcare interoperability standard, supports SOAP alongside REST. The IRS e-filing system is SOAP. Most European government tax APIs are SOAP.
SOAP was not popular because it was simple. It is anything but. It was popular because it solved real enterprise problems: strict contracts between services (WSDL), built-in error handling (SOAP Faults), platform-independent communication (XML is language-agnostic), and security standards (WS-Security) that REST took years to match.
Understanding SOAP matters even today, not because you will choose it for a new project, but because you will inevitably integrate with systems that use it. If you have ever worked with a payment gateway, a government API, or an ERP integration, you have probably seen a SOAP envelope.
A SOAP message is an XML document with a rigid four-part structure:
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Header>
<auth:Token xmlns:auth="http://example.com/auth">
abc123token
</auth:Token>
</soap:Header>
<soap:Body>
<m:GetStockPrice xmlns:m="http://example.com/stocks">
<m:Ticker>GOOG</m:Ticker>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>
Envelope: The root element. Declares the SOAP namespace. Every SOAP message starts and ends with this.
Header: Optional metadata. Authentication tokens, transaction IDs, routing info, WS-Security assertions. Intermediary proxies and ESBs can read headers without parsing the body.
Body: The actual request or response data. The operation name and its typed parameters. The WSDL contract defines exactly what shape the body must have.
Fault: Error information. Replaces the normal response in the body when an operation fails. Contains a machine-readable faultcode (soap:Client or soap:Server) and a human-readable faultstring.
WSDL (Web Services Description Language): The contract. A SOAP service publishes a WSDL file describing every operation, its parameters, return types, and endpoint URL. Clients fetch the WSDL and auto-generate code. Java developers use wsimport. .NET developers use wsdl.exe. The generated code handles serialization and deserialization automatically.
It is easy and good
“It is really nice and good Please join the course”