SOAP, REST and the Importance of Message brokers
In this article, I am going to discuss SOAP and REST. Let’s begin with a straightforward example: human communication. Language (both written and spoken), gestures, and facial expressions may all be used to describe our thoughts, needs, and ideas. User interface components such as a screen with a menu and graphical elements, a keyboard, and a mouse are required for interaction with computers, applications, and websites. To interact with each other, software or its components do not require a GUI and this is where API comes in. API is a software intermediary that allows two applications to talk to each other and it stands for Application Programming Interface. This works just like a waiter in a restaurant. So we place the order through the waiter and he or she will pass the order and once the food is ready, the waiter will deliver the food to us. So now I think you understand the idea behind the API.
Watch the following video if you want to clarify more on API,
So for online data transmission, there are 2 common approaches such as SOAP and REST. Let’s discuss it,
SOAP
SOAP stands for Simple Objects Access Protocol and it is a standard web communication protocol. SOAP programming is based on the XML language, which is a lightweight data transfer language in and of itself. It’s mostly used to expose web services and transmit data over HTTP (Hypertext Transfer Protocol)/HTTPS, SMTP (Simple Mail Transfer Protocol), and so on. When creating SOAP-based Web services, you’ll need a language that can be used to communicate with client applications. SOAP is an excellent tool for accomplishing this goal. The W3C organization, which is in charge of all web standards, also recommends this protocol. SOAP can manage communications and provide responses that are language and platform-independent because of its built-in ability for creating web-based services.
XML stands for Extensible Markup Language. It is a text-based markup language derived from Standard Generalized Markup Language (SGML).
Standard SOAP API requests and responses appear as a wrapped message with four components, each with its own set of functionalities.
Envelope is the main part of every message which envelops by starts and ends the messages with its tags.
Header is an optional part that determines extra components for the message such as authentication.
Body includes the request or response.
Fault is an optional component that displays complete information about any issues that may occur during the API request and response.
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
<ns1:RequestHeader
soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next"
soapenv:mustUnderstand="0"
xmlns:ns1="https://www.google.com/apis/ads/publisher/v202105">
<ns1:networkCode>123456</ns1:networkCode>
<ns1:applicationName>DfpApi-Java-2.1.0-dfp_test</ns1:applicationName>
</ns1:RequestHeader>
</soapenv:Header>
<soapenv:Body>
<getAdUnitsByStatement xmlns="https://www.google.com/apis/ads/publisher/v202105">
<filterStatement>
<query>WHERE parentId IS NULL LIMIT 500</query>
</filterStatement>
</getAdUnitsByStatement>
</soapenv:Body>
</soapenv:Envelope>This is an example of a SOAP XML request call in Google Ad Manager. Source: Google Ad Manager.
SOAP is most commonly used with business web-based software to maintain data security. Payment gateways, identity management, and CRM systems, as well as banking and communications services, all favor SOAP APIs.
REST
There was no standard on how to develop or utilize an API before 2000.
Its integration necessitated the use of protocols like SOAP, which were infamously difficult to develop, operate, and debug. When the actual potential of Web APIs was discovered in 2000, a group of specialists lead by Roy Fielding designed REST(also known as RESTful API), forever changing the API environment. REST stands for Representational State Transfer which is an architecture. The stated goal was to build a simple standard that would allow two servers to interact and share data from any location on the planet. As a result, they developed some principles. this supports messaging in different formats, such as HTML, csv, XML,xls/xlsx, and JSON, while SOAP only allows XML. Among these JSON is the most popular because it’s readable by both humans and machines. Usually its request or response in APIs. Headers and parameters are also important in the HTTP request. There is a set of criteria that must be confirmed for an API to be considered RESTful. such as,
- A client-server architecture should be there (including clients, servers, and resources with requests managed through HTTP).
- It has to be Stateless communication.
- Cacheable data that streamlines client-server interactions to improve the response times of requests.
- A uniform interface should be maintained components. (To maintain a standard form while transferring information).
- Each type of server is organized using a layered architecture.
Stateless means a service should not keep client information on the server while getting requests and there will be no connection between each request.
In REST, the client send(to get or change data) requests to the server and the server will respond to those requests. While making a request, there are 4 basic HTTP verbs are there to interact with data in REST,
- GET — to retrieve data (it is also possible to get data by specifying id)
- POST — to create a new data record
- PUT — to update the specific data based on the id we pass
- DELETE — to remove the specific data based on the id we pass
we also need to look into Header, Parameter, and Path while dealing with REST architecture.
The above 4 methods are also called CRUD operation. To learn more about CRUD click on the link below,
So in response, the server will send the respective data required by the client and it will also send HTTP Response codes which help to identify what sort of response is coming from the server. Let’s see some of the most common codes,
Let’s see how the request and response will look like,
There are websites to do dummy API request and one that I am doing is from https://dummy.restapiexample.com/
Let’s say that we are going to create a new record, for that we should use POST request under a certain endpoint for example,
Endpoint — http://dummy.restapiexample.com/api/v1/create
{
"name":"test",
"salary":"123",
"age":"23"
}In the above code, I used the POST method and it is in JSON format.
And let’s say that we need to get a particular data, so we have to specify the id of the record to fetch and for example, let’s fetch it from “http://dummy.restapiexample.com/api/v1/employee/1”. As you can see I have mentioned id 1 in the endpoint.
And this is how the response will look like. Actually, there is lot to say about the REST which will be discussed in future articles.
So what are the differences between SOAP and REST. Let’s have a look,
You know there are a lot of versions that came in HTTP, if you consider HTTP 1.0, it only allows one single request or response per connection. It is very time-consuming. If there are 3 requests coming from the client, the server will respond in the order they came as in the figure below,
When HTTP 1.1 came, it allowed multiple requests and responses in a single connection (Persistent connection). It saves so much time to keep on establishing the connection for each request. In here, for each request, the connection header value will be set to “Keep-Alive” in order to alert the server saying not to terminate the connection.
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Thu, 11 Aug 2016 15:23:13 GMT
Keep-Alive: timeout=5, max=1000
Last-Modified: Mon, 25 Jul 2016 04:32:39 GMT
Server: Apache
(body)The above section is an example of how the Keep-alive value is set in the connection header. (taken from: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive)
So the HTTP 1.1 flow will be like the figure below,
So you can ask then how the connection will be terminated? That is where TCP (Transmission Control Protocol) header flags come in. In the TCP header, there are 6 flags (URG, ACK, PSH, RST, SYN, FIN). So the client will set the FIN value as 1 to close the connection. This helps to send a request without waiting for acknowledgment. But still server respond to them in the order it arrives. Even though RESTful is Asynchronous still it works as Synchronous since REST work on top of HTTP. So to overcome this Message brokers should be implemented. So what is Message brokers ?.
Message Brokers
The general definition on the internet is “A message broker is a software that enables applications, systems, and services to communicate with each other and exchange information”. What actually happens is, let’s take a scenario where there is a client and a server (No message Brokers), the clients send four requests such as A, B, C, and D. And the processing time of these requests are 100ms, 5ms, 10ms, and 10ms respectively. Let’s assume these requests are coming simultaneously. What will be the response time of C ? It is 115ms. Because even though C finishes its execution before A, the response will be sent in the order it receives. So When we are using Message Broker in this scenario, It works as an intermediate section. So the server will send the response to the Message broker’s message queues whenever the execution is completed. The client will listen to the Message brokers and once the message broker gets the response from the server it will immediately send it to the client. So client no need to wait until other previous request to complete. So according to this scenario, the response time of C will be 10ms when using a Message broker. So as you can see ultimately message brokers making REST Asynchronous.
There are 2 Message Broker Model such as,
- Point-to-Point Messaging — This is basically a one-to-one relationship between the producer and the consumer and it uses a queue to store the messages. The producer sends the message to the queue, and the consumer gets the message from the queue and acknowledges receipt. Messages can be sent to the same queue by several producers, and messages may be retrieved from the same queue by several consumers. But this is only applicable when a message must be used only one time.
- Publish/subscribe messaging —This is a broadcast-style distribution method and it has a one-to-many relationship between producer and consumer. The producer is referred to as a publisher, while the customer is referred to as a subscriber under this model. On the same topic, one or more publishers can publish, and a message from one or more publishers can reach a large number of subscribers. Topics are subscribed to by subscribers, and all communications submitted to the subject are received by all topic subscribers.
When it comes to the advantages of using Message brokers are,
- It provides a seamless connection between services.
- It improves the performance of the system by providing asynchronous processing.
- It increases reliability by guaranteeing the transmission of messages.
RabbitMQ, Apache Kafka, Redis, Amazon SQS, and Amazon SNS are some of the examples of message brokers. In Java there is something called JMS and its stands for Java Message Service. It is a specification that is also one of the messaging services. For this, we need to use JMS API(Designed by Sun and several partner companies) which allows an application to create, send, receive and read messages.
I hope you will get have an idea about SOAP, REST and Message brokers to a certain level.
