What is the difference between REST and web sockets?

There are two communication models that are important for internet communication. One of which is the client-server model, which is applied in the World Wide Web; where a client (Google Chrome) can send requests to a server (Apache) and get a response with the HTTPS protocol. A client-server model is also applied in email systems; where a client (Outlook) can send requests to a server (MS Exchange) with protocols, such as POP, IMAP, SMTP, and so on.

There’s also the P2P (Peer 2 Peer) model that is applied in Filesharing, where peers (µTorrent) can send requests and responses to each other via BitTorrent protocol. P2P is also applied in cryptocurrency. Peers like Bitcoin Core, with a protocol (the cryptocurrency’s blockchain protocol), check on the protocols that cryptocurrency use.

How does a browser like Firefox communicate

1. It opens a connection to a server using a socket (IP and Port).

2. It talks to a server in a certain protocol.

3. It receives the response, parses it, and displays it.

Using sockets on the transport layer of the ISO/OSI model is protocol agnostic, which means it has no concept of URLs, methods, or anything similar; it only knows bytes. So if we want higher logic methods or URLs, which are required to access the different documents and execute different actions, we need a protocol on top.

Application programming interface

REST is an architectural style for structuring application access where each unique URL represents an object.

Ground principles of REST

Everything is a resource:

• Every data element of the application to be accessed is a resource with its own unique URI.

• The resource is just an abstract interface and not really an actual object or service itself.

• It is a good practice to use human-readable URIs (not mandatory): http://domain.com/endpoint?value=1.

Stateless communication:

• REST includes the concept of statelessness on behalf of the server, although there is a semblance of a state.

• All applications are either turned into resource state or managed by the client.

• All requests are independent of the previous requests (messages are self-contained and include all necessary information).

• The advantages of stateless communication include scalability and isolation of the client against changes on the server.

Standard methods:

• REST uses simple and uniform interfaces for all resources.

• HTTP verbs (POST, GET, PUT, DELETE) are used when implementing REST with HTTP.

• HTTP verbs are mapped to resource-specific semantics with REST.

Different representations:

• Resources should have multiple representations for different needs.

• Clients can ask for a representation in a particular format when using HTTP.

• An advantage of this is that different representations of a resource (HTML, XML, JSON, text, and so on) can be consumed by different clients all via the same interface.

Advantages of the RESTful approach

• Simplicity (URIs, HTTP methods, and no new XML specifications).

• Lightweight (messages are short).

• Multiple representations.

• Human-readable.

• Information can be cached.

• Low usage of resources.

• Ability to handle a heavy load.

• Secure (Authentication and authorization can be done by the web server).

• Scalability (multi-device usage/multiple servers).

• Reliability on recovering states.

• Easy service orchestration (no application boundaries).

Where REST is not applicable

REST is not the answer to everything, there are cases where REST is not just a good fit:

• When the server needs to notify the client (such as in a chat application).

• When it is mandatory to continuously send and receive data (such as in a Video Conference application).

• When it is mandatory to continuously send and receive data (such as in a Video Conference application).

Introducing web socket

Web socket is a bi-directional TCP-based network protocol standardized by IETF as RFC 6455 in 2011. It is supported by most modern-day browsers and gives freedom to parties of communication. Client-server and Peer-2-Peer (P2P) communication is possible and the server stays open for communication which makes it a good fit for high message frequencies, ad-hoc messaging, and fire-and-forget scenarios.

The new URL scheme we use for Web Socket (for websites) is ws instead of HTTP. On the other hand, for secure connections, wss is used instead of HTTPS.

How does it work?

1. The client sends an HTTP handshake request via the HTTP GET method.

2. Gateway (interface provider) sends an HTTP handshake response.

3. If the server can’t handle the request it responds with Status code 400: Bad request error

4. If the server can handle the request, the handshake is acknowledged.

5. Client requests Web Socket connection request.

6. Gateway establishes Web Socket connection.

Note: The client pushes data through the gateway. Client and server both push and receive messages using the bi-directional TCP connection.

Advantages of the web socket approach

• Two-way communication.

• Direct contact to browsers to reduce loading times.

• Lower overhead per message.

• Stateful connections (Without sending cookies or session IDs for every request).

• Can handle up to 1024 connections per browser.

• Cross-origin communications.

• High-speed and low latency connection.

• Lightweight.

REST vs web sockets

When to use REST API in HTTP

• For retrieving single resources.

• Stateless communication, application state is handled on client side.

• No frequent updates needed.

• Idempotency enables cachable resources.

• Handling of synchronized communication.

When to use web sockets

• Fast reaction time

• High frequent updates needed with small payloads

• Complex application state can be handled on the server side

• Fire-and-forget scenarios

• Constantly changing states (e.g., game states)

• Distribution of application state to multiple clients