Every API type you've learned so far follows the same pattern: the client asks, the server answers. You initiate, the server responds, the conversation ends. That model works for most things. It completely breaks for one category of feature: anything that needs to update in real time without the user doing anything.
Live chat. Collaborative document editing. Stock price tickers. Multiplayer game state. In all of these, the server needs to push data to the client the moment something changes, not wait to be asked.
WebSockets are how that works.
Why REST Fails at Real Time
Imagine building WhatsApp with REST. To show incoming messages, your app would have to ask the server every second: "Any new messages?" The server checks, finds nothing, responds "no." One second later, your app asks again. And again. Across a billion users doing this every second, the server load is catastrophic, and most of those calls return nothing useful.
This pattern is called polling, and it's the wrong tool for real-time features. The fundamental problem is that REST is stateless and request-driven. The server has no way to reach out to the client. It can only respond when spoken to.
WebSockets flip this model entirely.
How WebSockets Work
A WebSocket connection starts as a normal HTTP request, but with a special header that says: I want to upgrade this connection.
GET /chat HTTP/1.1
Host: yourapp.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
If the server supports WebSockets, it responds with a 101 Switching Protocols status, which means: agreed, HTTP is now gone, we have a WebSocket connection.
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
From this point, the connection stays open. Both the client and server can send messages to each other at any time, in either direction, without either side needing to ask first. One persistent connection replaces thousands of polling requests.
The Four Connection States
A WebSocket connection moves through four states. Getting these wrong causes real bugs.
Connecting (0) means the handshake is in progress. The connection is not ready yet. Sending a message here does nothing or throws an error.
Open (1) means the connection is live. Both sides can send and receive freely. This is the only state where sending messages is safe.
Closing (2) means one side has initiated a graceful shutdown. The connection is winding down.
Closed (3) means the connection is fully terminated. Attempting to send a message in this state crashes the connection. This is the most common beginner mistake: not checking the state before sending.
Always check that the connection is in state 1 before you send:
// Check state before sending to avoid crashes
if (socket.readyState === WebSocket.OPEN) {
socket.send(JSON.stringify({ type: "message", text: "Hello" }));
}
When to Use WebSockets, When Not To
Use WebSockets when the server needs to push data to the client without being asked. Live chat, real-time notifications, collaborative editing, live dashboards, multiplayer games, order tracking that updates as the delivery moves.
Skip WebSockets when you're just fetching data that the user requested. Loading a page, searching for restaurants, submitting a form: all of these are request-response patterns where REST handles the job cleanly. WebSockets maintain a persistent connection that consumes server resources for its entire lifetime. Using them where a single REST call would suffice wastes that resource across every connected user.
A useful rule: if the server ever needs to speak first, use WebSockets. If the client always speaks first, use REST.
What You Now Understand
REST asks, gets an answer, and the conversation ends. WebSockets open a persistent channel and keep it alive so both sides can speak freely at any time.
The handshake turns HTTP into a full-duplex connection. The four states tell you exactly what the connection is doing at any moment. And the core use case is always the same: server-initiated data that the client needs the moment it exists, not the moment it remembers to ask.
Your next step: open the browser console on any chat app or live dashboard and look at the Network tab filtered to WS. You'll see the WebSocket connection sitting open and messages flowing through it in real time. Watching it live is the fastest way to make the model concrete.
Top comments (0)