WEB Socket Vs REST Service

Overview

In this article, we’ll go through the basics of client-server communication and explore this through two popular options available today. We’ll see how Web Socket, which is a new entrant, fares against the more popular choice of RESTful HTTP.

Basic Of Networking Communication

Before we deep-dive into the details of different options and their merits and demerits, let’s quickly refresh the landscape of network communication. This will help with better understand this better. Network communications can be best understood in terms of the Open Systems Interconnection (OSI) model. As reprset in below HTTP & WebSocket present on application layer of OSI model.

At the top of this model is the Application layer which is of our interest in this tutorial. However, we’ll discuss some aspects in the top four layers as we go along comparing WebSocket and RESTful HTTP

The application layer is closest to the end user and is responsible for interfacing with the applications participating in the communication. There are several popular protocols which are used in this layer like FTP, SMTP, SNMP, HTTP, and WebSocket.

Basic Of Networking Communication

While communication can happen between any number of systems, we are particularly interested in client-server communication. More specifically, we’ll focus on communication between a web browser and a web server. This is the frame we’ll use to compare WebSocket with RESTful HTTP.

But before we proceed any further, why not quickly understand what they are!

What is REST :

REST (Representational State Transfer) is a set of architectural limitations, not a protocol or a standard. API developers can implement REST in a variety of ways. REST define one way to build API over HTTP.

It is very popular because of simplicity and the fact and the fact that it reuses the methods and technologies already used for the web.

REST (Representational State Transfer) is an architectural style which puts a set of constraints on HTTP to create web services.

HTTP is a stateless protocol and works in a request-response mechanism. On every HTTP request, a TCP connection is established with the server over the socket.

The client then waits until the server responds with the resource or an error. The next request from the client repeats everything as if the previous request never happened as below:

What is Web Sockets :

Web Socket is a communication protocol which features bi-directional, full-duplex communication over a persistent TCP connection. Fundamentally Web-socket provides an ongoing, low latency, two-way communication channel.Web socket open a connection and both sides can exchange messages as and when they need.Web socket is a communication protocol which features bi-directional, full-duplex communication over a persistent TCP connection.

This makes it ideal for real-time applications, such as chat, the live streaming of sports or financial data, and interactive, real-time collaborative environments like Figma, Miro, and Google Docs.

Web Socket was standardised as a communication protocol by IETF as RFC 6455 in 2011. Most modern web browsers today support the Web Socket protocol.

Let’s see what comprise a WebSocket handshake:

WebSocket works very differently compared to HTTP and starts with a handshake before actual communication.

As shown in above figure WebSocket, the client initiates a Protocol Handshake request in HTTP and then waits until the server responds accepting an upgrade to WebSocket from HTTP.

Of course, since Protocol Handshake happens over HTTP, it follows the sequence from the previous diagram. But once the connection is established, from there on client and server switches over to WebSocket for further communication.

WebSocket Vs REST Summary :

Key Characteristics Of WEBSocket & REST:

WebSocket :

• Persistent connection: Each REST request requires a fresh HTTP connection, which increases latency due to the overhead of the HTTP handshake. WebSocket opens a connection once and then keeps it open for as long as you need it, reducing the time it takes to send a message.
• Stateful: WebSocket’s persistent connection means that the client and server can keep track of what’s happened previously, rather than having to use cookies to track state, as with REST.
• Full duplex communication: Both the client and the server can send data whenever they need and at the same time. In REST, only the client can initiate a new connection.
• Payload format: WebSocket works with discrete messages, such as a JSON object or a Protobuf message. That’s in contrast with streaming media formats that send a constant flow of bytes. Importantly, WebSocket lets you send text or binary data and it’s up to you to handle serializing and deserializing that data.
• Realtime: WebSocket minimizes latency wherever possible. A persistent connection helps, as do small headers (as low as two bytes).?

REST :

• Stateless: Each request made to a REST API is independent and self-contained. That makes scaling much more straightforward. When traffic increases, you can add more servers behind a load balancer as there’s no need for a particular client to connect to the same server each time. Even though HTTP and REST are stateless, you can maintain long-running sessions by using client-side cookies to track session and log-in status.
• CRUD: Each REST request uses the standard HTTP verbs (GET, POST, PUT, PATCH, and DELETE), which lines-up with Create, Read, Update, Delete operations.
• Payload format: REST typically uses standardized message formats like JSON or XML for data exchange. But you can use whatever format of data you like, so long as you set the correct Content-Type header.?
• Cacheable: You can choose to allow clients, and intermediate infrastructure, to cache responses. That helps scaling and response times.
• Synchronous: The HTTP request-response cycle that REST relies on is best suited to short-lived, straightforward transactions where a client waits for response before moving on to the next task.

Where Should We Use ??

For the bulk of the scenario where occasional communication is required with the server like getting the record of an employee, it’s still sensible to use REST service over HTTP/S. But for newer client-side applications like a stock-price application which requires real-time updates from the server, it’s much convenient to leverage WebSocket.

Generalizing, WebSocket is more suitable for cases where a push-based and real-time communication defines the requirement more appropriately. Additionally, WebSocket works well for scenarios where a message needs to be pushed to multiple clients simultaneously. These are the cases where client and server communication over RESTful services will find it difficult if not prohibitive.

Key Characteristics

In this tutorial, we reviewed the basics of network communication with an emphasis on application layer protocols HTTP and WebSocket. We saw some quick demonstrations of WebSocket and RESTful API over HTTP.