REST API (HTTP) vs Websockets – Concept Overview With Example

Whats the difference between a REST API (HTTP) and Websockets? Learn through a practical example in this article. If you enjoy learning in video form, check out my YouTube video on this article here.

1. Overview

In this article, we’ll explain the difference between a REST or HTTP API vs Websockets.

Choosing a REST based API over Websockets is an important design consideration of any applications. We’re going to look at the difference between these two by analyzing how we would build a real time chatting application. We’re going to look at a solution using REST and a solution using Websockets. We’ll also discuss some of the pros and cons of using either approach.

2. REST Based Approach

Imagine we have two users, John and Mary. John and marry need to communicate with eachother over a web based application. To facilitate the conversation, we have a backend server that will orchestrate the communication between John and Mary’s front end clients, and a database to store messages and history.

The scenario looks a little bit like what we have below

Now our client John wants to send a message to Mary’s application. It does so by sending a POST request to a HTTP endpoint on the backend server. The call contains details about the room id that both users are in, and the payload of the message.

The server receives the message and saves it in its database.

But now we’ve hit a problem. How will Mary’s client get notified of the new message that john just sent?

So far, our example looks like this:

To solve for this, Mary’s application would need to somehow become notified that a new message was present by John. But how can it do this?

The answer is polling. Polling is a simple concept – its basically just a fancy word for “check for state continuously”. In our case, Mary’s application needs to continuously call our backend server, or poll it, in order to “discover” new messages in the chat room.

Do you see the problem with this approach?

Its quite inefficient. Every couple seconds all client applications (including john and mary) will be calling our backend servers, clogging them with requests. As our userbase grows, the amount of backend requests will grow. This could have performance implications and even cost implications for our servers.

To round out the example – Mary’s client would then poll the backend server to the /messgage API, discover the new content that John just sent, and display it on her web app as seen below.

Both John and Mary’s web applications would poll for new content to be discovered from the server, and transmit new messages sent.

Now that we’ve understood how a REST based approach may look like, lets look at how a Websocket based approach would work.

2. Web Socket Approach

In a Websocket based approach, we may have of the same actors and connections, but some of the roles are altered.

In the Websocket model, our web applications are configured to establish a connection to the backend server on page load.

The server’s role is not necessarily to store copies of the messages in its database, but rather to be the facilitator of communication between 2 or more parties.

To do this, the web-server web servers track all client connections and have the ability to “publish” messages to certain “subscribers”.

In our example, John and Mary would be linked via their Room Number – 101 in this case. When John sends a message to the server, the server looks up all other clients that are linked with Room 101, and broadcasts a message to them.

In other words, this model uses a publish/subscribe as opposed pull-based or polling model.

One of the benefits of using this approach is much more “realtime” message delivery. Since messages are received and thus published very quickly by the server, there are minimal delays in new messages from one party being transmitted to the receiving party.

A drawback though is the extra workload our server needs to manage. Instead of being relatively stateless in our REST based approach, our server needs to now track and manage connections and message receipt / delivery.

One might be advised to use a scalable web socket based hosting platform, as is offered through AWS API Gateway with Websockets.

Regardless of which method you choose, there are a number of pros and cons with either approach. At a minimum, I hope this article has helped you understand the difference between these two technologies.