How different between "WebSocket" and "REST API"

Question

I always use REST API when I get or post some data. But WebSocket can also do that.

So, I am confused about the difference between WebSocket and REST API when I try to get or post some data.

Answer 1

WebSockets are, just like sockets, an interface between two adjacent layers.

Specifically, in ARPANET reference model, sockets are an interface between Transport layer and Application layer; in OSI reference model, they represent an interface between Session layer and Transport layer. Interface means that they reside "in between" layers (at their boundary).

WebSockets are the sockets interface that was "migrated" from the Session/Transport layer boundary to the Session/Presentation boundary of the OSI model. This was done in order to overcome limitations of sockets in the world of web where all communications are "free" by default only on the port 80, the port of HTTP traffic. HTTP protocol, which sits on top of (guaranteed delivery) TCP Transport layer, is part of the Session layer in OSI model thus it can be considered as a "transport" as well for the layer above, the Presentation layer.

Since "I" in "API" stands for "Interface", both sockets and WebSockets are a form of API, although the term API belongs to a modern jargon. REST API is also an interface between Session and Presentation layers of the OSI model.

The difference between the REST API interface and WebSockets interface is that WebSockets is a full duplex persistent TCP connection established via 3-way handshake protocol over HTTP. REST API over HTTP is, just like HTTP, a Request/Response (non-standard) protocol where a TCP connection is created on each new request i.e. it is not persistent.

Answer 2

A REST API uses HTTP as the underlying protocol for communication, which in turn follows the request and response paradigm. However, with WebSockets, although the communication still starts off over HTTP, it is further elevated to follow the WebSockets protocol if both the server and the client are compliant with the protocol (not all entities support the WebSockets protocol).

Now with WebSockets, it is possible to establish a full duplex and persistent connection between the client and a server. This means that unlike a request and a response, the connection stays open for as long as the application is running, and since it is full duplex, two way simultaneous communication is possible i.e now the server is capable of initiating a communication and 'push' some data to the client.

This is the primary concept use in the realtime technology where you are able to get new updates in the form of server push without the client having to request (refresh the page) repeatedly. Examples of such applications are Uber car's location tracking, Push Notifications, Stock market prices updating in realtime etc.

Here's a video from a presentation I gave earlier this month about websockets and how they are different than using the regular REST APIs: https://www.youtube.com/watch?v=PJZ06MLXGwA&list=PLZWI9MjJG-V_Y52VWLPZE1KtUTykyGTpJ&index=2

Answer 3

I haven't yet fully understood what a REST API is, but I guess you refer to it in a broarder way so as to web systems that provide structured data referd to a specific resource as can be a customer, or a product, upon a POST or GET call over http.

The main difference from a practical and simplistic approach is that HTTP GET / POST are request - response protocols. The server will send a response upon a request sent by the client.

In the case of Websockets, communication is bidirectional. Either the server or the client can send information to the counterpart at any time.

To visualize the difference a page that provides stock market data if using HTTP GET will issue a new request to the server each X seconds to get the updated price. Using websockets, the SERVER could directly send the new price to the web browser as soon as it has changed.

You may also be interested in looking into long polling which is a techinc used with HTTP GET / POST to provide similar functionality as Websockets (though it is a totally different thing)

Answer 4

You can provide a REST API along with a WebSocket API for different purposes. It's up to your requirements and it depends on what you want to achieve.

For example, a WebSocket API can be used to provide real-time notifications while the REST API can be used to manage your resources.

There are a few details you should be aware of:

• REST is a protocol independent architectural style frequently implemented over the HTTP protocol and it's supposed to be stateless.
• WebSocket is a bi-directional, full-duplex and persistent connection protocol, hence it's stateful.

Just to mention one example of application that provides different APIs: Stack Exchange provides a REST API along with a WebSocket API.