SOAP, REST, HTTP, and Message Brokers
This article will give you a good understanding of SOAP, REST, HTTP, and message brokers.
SOAP
Simple Object Access Protocol (SOAP) is a web communication protocol designed for Microsoft in 1998. SOAP follows the XML data format this implies when a request is received, SOAP APIs send the response in XML format. The requests and responses of SOAP APIs appear as an enveloped message as follows (refer to figure 1).
- Envelop: This is a core element in every SOAP message which defines the beginning and end of the message with tags.
- Header: This is optional but this defines requirements for authentication, etc.
- Body: Defines the response or request.
- Attachments/Error : This is optional and this defines the errors that occurred while processing the message.
Refer to the following code snippet.
<?xml version="1.0"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:m="http://www.example.org"><soap:Header></soap:Header><soap:Body><m:Name><m:FirstName>T</m:FirstName ></m:Name></soap:Body></soap:Envelope>
Here HTTP, SMTP, TCP, and HTTS are valid protocols use in the application layer.
REST
Representational State Transfer (REST) is an architecture that is used to create lightweight web services. In this architecture, both client and server implementations can be done independently. This implies both codes of the client and server-side can be changed at any time without making any harm to each other. Usually, the systems that follow the REST architecture are stateless. That implies both client and the server do not need to know the current states of each other.
When a client creates a request to retrieve or modify the data on the server, the request is a composition of;
- HTTP verb: Defines the CURD operation (POST, DELETE, PUT, GET)
- Headers: Includes the information about the request.
Headers there is a field called Accept. This is responsible for defining the type of content that the client can receive. As an example, to receive HTML files Accept should be text/html (type/subtype).
- Path to the resource
- Request body (This is optional).: The body of the request.
When receiving the response to the client there is another field called content-type defined in the header of the response. This defines the type of data in the response body received by the client. As an example, to receive the response in JSON format, the content-type should be application/json. The following figure 2 shows the output of an HTTP request with Postman.
Response codes are used to alert the client to provide information about the success of the operation. The following figure 3 defines some of the response codes currently in use.
Below table 1 defines the differences between SOAP and REST.
HTTP/1.0 vs HTTP/1.1
As per the above figure 4, in HTTP/1.0, the TCP connection is established per request and the session will remain until the server sends the response. But this is not happened in HTTP/1.1, because the default session is being stayed open and multiple requests can be passed across.
Developers can implement the REST as asynchronous and synchronous. That implies this can be implemented to return data for requests either immediately or at a later time, respectively. Even though HTTP/1.1 allows clients to send requests without making any delay, servers send the responses according to the received order. To make this asynchronous need to use a middleware called Message Brokers.
Message Brokers
A message broker acts as a middleware in communication between two entities and this provides a way to exchange messages between the client and the server. Refer to figure 5.
There are 2 approaches used by message brokers;
- Point-to-point messaging
Here there is a one-to-one relationship between the sender and the receiver that implies each message is sent and consumed only once. This will guarantee that the sent message by the sender will not be lost in case of failure of the consumer and this is stored safely in the message broker queue. Refer to figure 6.
- Publish/Subscribe
Here publisher sets the message to a topic and endpoints can subscribe to the specific topic and can access the message. Refer to figure 7.
Apart from that, there are more variant approaches used by message brokers.
Some of the examples for message brokers,
- Apache Kafka
- RabbitMQ
- Apache Pulsar
- Amazon Web Services (AWS) Amazon MQ
- Amazon Web Services (AWS) Kinesis
- Apache ActiveMQ
- Apache Qpid
Conclusions
- SOAP is a protocol and REST is an architecture.
- SOAP transmits the data in XML format but REST allows to transmit data in many formats.
- Message brokers are used to making the REST implementations asynchronous.
References
