SOAP vs REST

1. Introduction

From simple mobile applications to advanced corporate platforms, exchanging information between different programs has become an integral part of everyday operations. Application communication enables integration, collaboration, and efficient resource utilization, contributing to increased flexibility and effectiveness of information systems.

There are various protocols, standards, and technologies that facilitate communication between applications.

2. The HTTP protocol

The HTTP protocol is often used in conjunction with the TCP/IP (Transmission Control Protocol/Internet Protocol), operating at the transport layer. Its operation is based on several steps:

1) Session initiation – The client initiates a connection with the server, typically by opening a new socket. The client and server identify each other, usually using IP addresses and ports.

2) TCP Handshake (optional) – if the TCP protocol is used (which is standard for HTTP), a connection establishment process called “three-way handshake” may occur. It is a series of messages between the client and server to establish connection parameters.

3) Request sending – The client sends a request to the server. The structure of the request includes:

• Request Line: Contains the method (GET, POST, etc.), the resource path, and the HTTP protocol version.
• Headers: Convey information such as User-Agent, Host, Content-Type, etc.
• Blank Line: Separates headers from any data in the request body.
• Body: Optional data, often used in methods such as POST.

4) Server processing – The server receives the request, analyzes it, and decides how to respond. This may involve delivering requested resources, processing data, saving information, etc.

5) Response sending – The server generates a response, which includes:

• Status Line: Contains the status code (e.g., 200 OK) and the HTTP protocol version.
• Headers: Convey information such as Content-Type, Content-Length, etc.
• Blank Line: Separates headers from the response body.
• Body: Optional data, such as the page content.

6) Session termination – After completing the data exchange, the session can be closed, releasing resources and closing the socket, unless the keep-alive technique is applied, making it possible the reuse the connection for future requests.

It’s worth noting that the HTTP protocol is stateless, meaning each request is handled independently of the previous ones. The stateless nature of HTTP facilitates scalability and provides flexibility in the communication between the client and the server.

3. SOAP

SOAP (Simple Object Access Protocol) communication refers to the process of exchanging structured information between programs using the SOAP protocol. SOAP is a communication protocol based on XML (Extensible Markup Language), and its primary purpose is to make interoperable communication between different systems and applications possible, regardless of the platform or programming language.

3.1. XML Structure:

SOAP messages are typically described using the XML language, allowing the representation of structured data. Within a SOAP message, information is usually organized in the form of XML elements, facilitating their processing and interpretation. A SOAP message looks as follows:

<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<soap:Header>
<!-- Dodatkowe informacje kontrolne -->
</soap:Header>
<soap:Body>
<!-- Dane przetwarzane przez komunikat -->
</soap:Body>
</soap:Envelope>

a) Envelope (Wrapper):
All elements of the SOAP message are encapsulated in the so-called “envelope.” This is the main element that surrounds the entire content of the message.

b) Header:
The soap: the header element is optional and contains additional control information that can be used by client and server applications.

c) Body:
The soap: the body element contains the actual data processed by the message. It is in this element that operations (methods) performed on the remote server are placed.

3.2. Communication Protocol:

SOAP defines a standardized way of formatting messages exchanged between applications. The typical carrier for SOAP communication is the HTTP protocol, although SOAP can also be used with other transport protocols such as SMTP or MQ (Message Queues).

3.3 Methods (Operations):

SOAP communication involves various methods (operations) that identify specific actions to be performed on a remote server. These methods are defined in what is called “web services.”

WSDL (Web Services Description Language):

A WSDL (Web Services Description Language) file is an XML document used to describe the interface of a web service. WSDL defines what operations (methods) are available in the service, what parameters and data types are used, what the service endpoints are, and what communication protocols are supported. Here are the main elements you can find in a WSDL file:

1) Definitions:
The beginning of the WSDL file contains the element, which is a container for all service-related definitions.

2) Types:
The element can contain definitions of data types used in the service operations. WSDL supports various data types, such as simple types (int, string) and more complex composite types (e.g., data structures).

3) Message:
The element defines the structure of a message sent between the client and the server. Each message consists of one or more elements.

4) PortType:
The element defines operations available in the service and the structure of messages sent during those operations.

5) Binding:
The element connects the abstract portType with concrete implementation details, such as the communication protocol and message format (e.g., SOAP).

6) Service:
The element defines a specific access point to the service, containing one or more ports.

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
name="HelloWorldService"
targetNamespace="http://example.com/HelloWorldService">

    <message name="SayHelloRequest">
        <part name="name" type="xsd:string"/>
    </message>

    <message name="SayHelloResponse">
        <part name="greeting" type="xsd:string"/>
    </message>

    <portType name="HelloWorldPortType">
        <operation name="SayHello">
            <input message="tns:SayHelloRequest"/>
            <output message="tns:SayHelloResponse"/>
        </operation>
    </portType>

    <binding name="HelloWorldSoapBinding" type="tns:HelloWorldPortType">
        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
        <operation name="SayHello">
            <soap:operation soapAction="http://example.com/HelloWorldService/SayHello"/>
            <input>
                <soap:body use="literal"/>
            </input>
            <output>
                <soap:body use="literal"/>
            </output>
        </operation>
    </binding>

    <service name="HelloWorldService">
        <port name="HelloWorldPort" binding="tns:HelloWorldSoapBinding">
            <soap:address location="http://example.com/HelloWorldService"/>
        </port>
    </service>
</definitions>

The example above illustrates:

• Only one operation named SayHello has been defined.
• The SayHelloRequest and SayHelloResponse messages are simple and contain single fields.
• The service operates in the namespace http://example.com/HelloWorldService.

The WSDL file is crucial for web services as it provides clients with information about available operations, how to invoke them, and the data format used in communication. This enables clients to dynamically generate code for communicating with the service, and facilitating integration between different systems. On the other hand, it is possible to generate the WSDL file basing on the existing implementation.

SOAP or REST

SOAP

Definition – A communication protocol based on XML for exchanging data structures.
Data Format – Typically uses XML
Transport Protocol – Can use various protocols (e.g., HTTP, SMTP, JMS)
Stateful/Stateless – Can be both stateful and stateless
Idempotence – Typically not idempotent
Interface – Emphasis on formal operations, uses WSDL
Transactions – Supports transactions through ACID standards
Security – Extensive security features (e.g., WS-Security)
Browser-Friendly – Less browser-friendly, more challenging to implement in web clients
Use Cases – Often used in complex enterprise systems, service-oriented architectures
Performance – Typically requires more resources and bandwidth

REST

Definition – An architectural style based on resources and operations on them
Data Format – Typically uses lighter formats such as JSON, XML, or HTML
Transport Protocol – Typically uses the HTTP protocol
Stateful/Stateless – Stateless
Idempotence – Typically idempotent
Interface – A simple resource-oriented HTTP interface
Transactions – Typically relies on resource-based transactions
Security – Typically relies on HTTPS and security tokens
Browser-Friendly – More browser-friendly, easier to implement in web clients
Use Cases – Popular in web applications, APIs, microservices
Performance – Typically more efficient and lightweight, advantageous in resource-constrained environments

Conclusion

It’s important to note that the choice between SOAP and REST depends on the specific project requirements, and both technologies have their place in different contexts based on project specifics and functional requirements.