Name: Avipsa Ghosh
Class: CE2
Roll no: 19
IOT ASSIGNMENT 5
Explain web socket based communication API with suitable diagram.
compare it with REST based communication API
WebSocket-based communication and REST-based communication are two distinct
approaches to client-server communication, each with its own strengths and use cases. Let's
break them down, compare them, and explain WebSocket in detail.
WebSocket-Based Communication API
What is WebSocket?
WebSocket is a full-duplex communication protocol that enables persistent, bidirectional
communication between a client and a server over a single TCP connection. This is useful for
real-time applications such as chat apps, online gaming, stock price updates, etc., where
continuous data exchange is necessary.
How Does WebSocket Work?
1. Handshake: WebSocket starts with an HTTP handshake. The client sends a
WebSocket request to the server, which upgrades the HTTP connection to a
WebSocket connection if the server supports it.
2. Persistent Connection: Once the connection is established, the client and server can
send messages to each other at any time.
3. Full-Duplex Communication: Both the client and server can push data to each other
simultaneously without needing repeated requests.
4. Low Latency: Since the connection remains open, there's no need to reestablish a
connection for each message, resulting in lower latency and overhead.
Real-time, bidirectional communication: Both server and client can send messages
whenever needed without initiating a request.
Efficient for frequent, small updates: Low overhead compared to HTTP because it
eliminates the need to send headers with every request.
Low latency: Keeps the connection alive, making it highly responsive.
REST-Based Communication API
What is REST (Representational State Transfer)?
REST is an architectural style for designing networked applications. It works over HTTP and
uses stateless communication. Each request from the client to the server is independent,
meaning no persistent connection is required.
How Does REST Work?
1. Client Sends HTTP Request: The client sends an HTTP request to the server,
usually using methods like GET, POST, PUT, or DELETE.
2. Server Processes Request: The server processes the request and sends an HTTP
response with the requested data or status.
3. Stateless Communication: Each request is independent of previous requests. There is
no persistent connection or session.
Key Features of REST:
Stateless: Each request from the client contains all the information needed to process
it. No need to maintain session data between requests.
Well-suited for CRUD operations: It is ideal for situations where the client and
server communicate by exchanging resources (like JSON or XML data).
Easy to implement: REST is simple, with clear methods (GET, POST, PUT, DELETE),
and relies on HTTP, which is widely supported.
Comparison: WebSocket vs REST
Feature WebSocket REST
Communication
Full-duplex, bidirectional Request-response, stateless
Model
Connection Persistent Non-persistent
Low (due to single
Overhead Higher (repeated HTTP requests)
connection)
Higher latency due to re-establishing the
Latency Low latency
connection each time
Ideal for real-time data (chat,
Real-time updates Not ideal for real-time updates
games, etc.)
Live updates, notifications, RESTful APIs, CRUD operations, web
Use cases
games, chats services
Text or binary data (protocol-
Data exchange Typically JSON or XML over HTTP
agnostic)
When to Use WebSocket:
Real-time applications like chat systems, live notifications, or live data feeds (stocks,
sports scores).
Applications requiring continuous, low-latency communication between client and
server.
When to Use REST:
REST is suitable for applications that involve CRUD operations (Create, Read,
Update, Delete), such as web services for accessing and managing data.
It is best for simple, non-real-time interactions.
Both WebSocket and REST have their own strengths, and the choice depends on the specific
use case—whether the application requires real-time interaction or can work well with the
traditional request-response model.
