A dialogue for REST vs Web Sockets style of connection

Scenarios regarding what is to be used when and where.
Let’s dive in and start with an example.

Most of us are familiar with PC gaming and gaming console heavyweights née Xbox and PlayStation.Nowadays a lot of great games are being released which are cloud based. Both have a certain mojo associated with them, but the point where cloud games really ace over the consoles is that they don’t require intensive and heavy hardware on the client (aka. player) side as most of the processing and calculations are done in the cloud. One data center can serve ten’s of thousands of requests per second. As on the other hand Xbox and PS have some of the greatest games but the big problem with them is their very own hardware as everyone has to get their own to join in the fun. If we have a cumulative for the consoles we get a huge number.

Let’s look into another example for a better understanding of where we are heading.

Consider you are a general in a army currently at war with another country. Apart from artillery the most important thing at your disposal is how well you are connected with all your units. Communication is important and walkie-talkies are the instruments used for the same. The way that walkie talkie works is that we press a button and speak our message and the receiver listens to the message and then the receiver follows the same process. It is good when we are not in a hurry, or we don’t have a lot of work to accomplish. But when you are in an active war zone even a millisecond delay can cause a lot of harm so the line between the receiver and the sender is to be kept open for the period. It saves a lot of time of button pressing and other monkey business.

About REST
REST is the standardized way of structuring the API for requests. REST stands for REpresentational State Transfer. It is another abstraction for creating API’s for applications in a standardized way. Vast majority of applications are architected in this way. REST uses common HTTP verbs such as GET, POST, PUT etc to send and receive data. It is very useful technique for generating applications as it gives many ways to connect to the server and do data transfers, but there is a major disadvantage in the way the connections are created for the transfer. Whenever a HTTP connection is created a certain overhead is also created with the same. It is necessary and the explanation for that is beyond the scope of this article. When many such call are created in very rapid succession it leads to congestion in the network and the overheads usually eat all the bandwidths which we don’t want.

Applications where REST is used are-

API design, Web apps which create requests based on events etc.

About Sockets
REST worked on the principle of HTTP connection. You create the connection do your data transfer and close the connection. Websockets are too based on the same principle but the difference is that we can keep the connection open for as long as we want. It takes the disadvantages of REST away as we only need to create the connection once. Overhead problem solved. Voila!. But websockets come with their own problem, keeping a persistent connection open for such long time is also a complex process, but is advantageous in the long run. It is not recommended to make open connections for small requests. We have REST for that.

Applications where sockets are used are-

Chat applications, Online games, Live Document collaboration etc.

Now about the examples and the analogy
The consoles and button pressing are REST calls and Cloud gaming + No button connection are a websockets connection. When there is a heavy use of continuous exchange of data between client and server in very short intervals we should go for websockets connection as it tends to keep the connection open until all the transfers are done. REST can also be used for the same but the problem with REST is that they create an overhead every time a connection is created (the consoles) because creating a connection requires a lot of steps like handshakes for example. Closing and opening it again and again every 1 ms interval can prove very heavy for the application or the system in general. It does not say that one is better then another because both have their strong points and their respective usage areas. Say we need to make a request every 30 min then it will be a foolish decision to leave the connection open for so long( websockets) as it will only eat unnecessary bandwidth. REST is mostly used in applications which do not require heavy data exchange in short intervals which websockets are used precisely in such conditions.

In the end both are two sides of a coin 💰. Both are needed and are super useful with different use-cases which the developer should decide carefully what to use to increase the efficiency of their product.

Cheers 🍻

Clap 👏 and Comment! 🤷