What is a Socket?

A socket can be thought of as a channel or gateway through which data goes in and out. It serves as an endpoint for communication between two processes in the same machine or different machines over a network connection.

There needs to be a way of standardizing the way data is transferred and interpreted over the socket by establishing a set of rules or protocols. One such protocol is HTTP(Hyper Text Transfer Protocol). HTTP had a few drawbacks in certain use cases which led to the establishment of another protocol called the WebSocket protocol. But before moving into WebSocket, let us see the limitations faced by HTTP which was subsequently resolved by WebSocket.

Limitations of HTTP
  • Every time a new request is made to the server a new socket is opened and then closed once the data transfer is over. This resulted in an unnecessary overhead of opening and closing the socket, hence making it unsuitable for real-time communication.
  • Even if there was any change in data on the server-side, the server had no way to communicate the change to the client unless and until a request is made to the server from the client.

WebSocket, on the other hand, got rid of these limitations by keeping the socket open for communication after a handshake is established with the server and keeping it open until it has been closed explicitly and in turn getting rid of the overhead of opening and closing the socket, each time a new request is made. It also supported bi-directional data flow i.e. both server and client can send data independent of each other and the client wouldn't have to make a request each time to check if there is any change on the server-side.

What is REST?

REST stands for Representational State Transfer. It is not a protocol in itself and hence it is not ideal to perform a comparison between REST and WebSocket but since it uses HTTP for communication underneath, the advantages and limitations attached with HTTP get automatically linked to it. REST is a standardized architectural way or style to structure the API for requests.

So one question that may arise is why not use WebSocket all time? For use cases say when a user is reading a blog, there is no point in keeping the socket connection open even though the user is not making any request to the server and in such cases keeping the connection closed will save resources. And hence using REST here will be more justifiable from a performance point of view.

A metaphorical example

Metaphorically speaking, REST can be viewed as a restaurant where the waiter is the server and the customers are the browsers. If any customer needs to set a new order he/she needs to request the waiter and the waiter will either accept or reject the order.

But every time a customer needs update regarding whether their order is ready or not then they will need to ask the waiter regarding that and there will also be an additional delay for each customer to get a response to their query since the waiter will be able to respond to only one customer at a time and other customers have to wait until their turn comes.

On the other hand in case of WebSockets the customers wouldn't have to request the waiter to get update on his/her order rather the waiter will be able to broadcast the updated order information whenever any order is ready and its on the waiter whether he/she wants to pass the message to a particular customer or all the customers present in the restaurant. As a result the customers won't end up wasting their time getting an update on their order, rather enjoy their time at the restaurant.

The decision regarding whether to use Websocket or REST/HTTP relies solely on the use case and the resource constraints. We at Probyto use websockets in projects involving real time communication like chatbots and rely on REST when building products where the need for real time updates is considerably negligible.