Understanding SOAP: The Old Guard of Web Services
Introduction
As we know in the web services world, RESTful APIs are the best and first choice for developers when they choose their API architecture. However, before REST became very popular and used architecture software, there was another protocol that dominated the web services in the software industry, called SOAP (Simple Object Access Protocol).
So, according to this title, the post will explain and teach a little about SOAP, its brief history, SOAP Message Structure, popular applications and platforms that support and use SOAP and Architectures That Emerged After SOAP.
To make this more interesting, we will create a simple example of a SOAP API, implementing CRUD (Create, Read, Update, Delete) using Python.
What is SOAP?
SOAP, which stands for Simple Object Access Protocol, is a network protocol for communication between applications. It works over application layer protocols such as HTTP and SMTP for notifications and transmission, using XML as the format for transferring messages.
SOAP (XML) messages typically contain an envelope that includes a header and a body.
A Brief History of SOAP
SOAP, conceived in 1998 by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein at Microsoft, initially as XML-RPC in Frontier 5.1, aimed to facilitate object access. The specification was submitted to IETF on September 13, 1999. By 2001, with the stabilization of W3C’s XML Schema and the establishment of the XML Protocol Working Group, SOAP gained broader acceptance. WSDL emerged as a metadata standard, advancing interoperability efforts. Despite initial delays, SOAP rapidly evolved into a key component of web services architecture due to its ability to facilitate platform-independent communication.
SOAP Message Structure
As was said at the beginning, SOAP uses XML for transmission messages and the elements of the message are:
- Envelope: Is the root element of a SOAP message. It encapsulates the entire message and defines the XML namespace for SOAP.
- Header: Is an optional element and contains application-specific information related to the SOAP message. It can include authentication credentials, message routing details, or other metadata.
- Body: Is a mandatory element and contains the actual payload of the SOAP message. It carries the data being transmitted between the client and the server. The content of the body is defined by the application-specific schema.
- Fault: Is an optional element and is used to report errors that occur during the processing of the SOAP message. It contains information about the fault, such as fault code(Client, Server, MustUnderstand, VersionMismatch), fault string, and fault actor.
Example SOAP Message:
- Successful SOAP Response
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: [length of the SOAP response body]
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<!-- Header content here -->
</soap:Header>
<soap:Body>
<m:GetProductResponse xmlns:m="http://example.org/stock">
<m:Product>
<m:id>1001</m:id>
<m:name>Coca Cola 2L</m:name>
<m:quantity>321</m:quantity>
<m:price>30</m:price>
</m:Product>
</m:GetProductResponse>
</soap:Body>
</soap:Envelope>
- SOAP Fault Response
HTTP/1.1 500 Internal Server Error
Content-Type: text/xml; charset=utf-8
Content-Length: [length of the SOAP response body]
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<!-- Header content here -->
</soap:Header>
<soap:Body>
<soap:Fault>
<faultcode>soap:Client</faultcode>
<faultstring>Invalid request: Missing required element 'id'</faultstring>
<faultactor>http://example.org/stock</faultactor>
<detail>
<m:ErrorDetails xmlns:m="http://example.org/errors">
<m:ErrorCode>400</m:ErrorCode>
<m:ErrorMessage>The 'id' element is required but was not found in the request.</m:ErrorMessage>
</m:ErrorDetails>
</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
SOAP messages are usually sent over HTTP using a POST request, as illustrated in the example below:
POST /your-soap-endpoint HTTP/1.1
Host: your-server.com
Content-Type: text/xml; charset=utf-8
Content-Length: [length of the SOAP request body]
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<!-- Header content here -->
<auth:Authentication xmlns:auth="http://example.org/auth">
<auth:Token>mytoken</auth:Token>
</auth:Authentication>
</soap:Header>
<soap:Body>
<!-- Body content here -->
<m:GetProduct xmlns:m="http://example.org/stock">
<m:id>1001</m:id>
</m:GetProduct>
</soap:Body>
</soap:Envelope>
POST /your-soap-endpoint HTTP/1.1
Host: your-server.com
Content-Type: text/xml; charset=utf-8
Content-Length: [length of the SOAP request body]
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<!-- Header content here -->
<auth:Authentication xmlns:auth="http://example.org/auth">
<auth:Token>mytoken</auth:Token>
</auth:Authentication>
</soap:Header>
<soap:Body>
<!-- Body content here -->
<m:GetProduct xmlns:m="http://example.org/stock">
<!-- Missing the ID element -->
</m:GetProduct>
</soap:Body>
</soap:Envelope>
Popular Applications and Platforms that Use SOAP
SOAP remains a vital protocol in some industries. Some popular applications and platforms that use SOAP include:
- Microsoft Azure: Azure’s web services often provide SOAP endpoints for enterprise-grade applications.
- Amazon Web Services (AWS): AWS supports SOAP for various services, including AWS Simple Queue Service (SQS) and AWS Simple Storage Service (S3).
- Payment Gateways: Many payment gateways, such as PayPal and Authorize.Net, offer SOAP APIs for secure transactions.
Architectures That Emerged After SOAP
After SOAP, several architectures emerged, bringing simplicity, flexibility, and performance improvements. These architectures include:
1. REST (Representational State Transfer): RESTful APIs gained popularity due to their simplicity, stateless nature, and use of standard HTTP methods. REST is lightweight and easier to implement compared to SOAP.
2. GraphQL: Developed by Facebook, GraphQL provides a more flexible and efficient way to query APIs. It allows clients to request specific data and aggregate multiple resources in a single request.
3. gRPC (gRPC Remote Procedure Calls): Created by Google, gRPC uses HTTP/2 for transport, Protocol Buffers as the interface description language, and provides features such as bi-directional streaming and advanced authentication.
Bye!
Thank you for reading. Please be aware that in the upcoming post, I will provide an example of how to create a simple SOAP API with Python.
Feel free to suggest any important points about SOAP that were not mentioned here.
