WebSocket

On screens where the browser needs to learn about server-side state changes quickly, the request-response model becomes awkward fast. If a client polls a REST API every second just to check whether a new message arrived, requests keep going out even when nothing changed. If the polling interval is increased, the user sees changes long after they actually happened. This wastes both server capacity and network bandwidth. The more frequently the state changes -- chat, dashboards, collaboration tools -- the more natural it becomes to have the server notify the client when something changes instead of forcing the client to keep asking.

The early web was primarily about retrieving documents, so HTTP's request-response model was sufficient. But as AJAX spread and browsers began hosting application-like services, demand for real-time interaction grew. Chat, stock tickers, games, and collaborative editing all require state to keep flowing in without a manual refresh. Long polling and Comet were workarounds, but the core limitation remained that HTTP kept opening interactions one request at a time. WebSocket changed the model by establishing a connection once and keeping that channel alive, allowing the browser and server to behave more like peers in an ongoing conversation.

WebSocket does not begin as a completely separate protocol. The browser first sends an HTTP request, and if the server accepts the Upgrade headers, the same TCP connection is switched into a WebSocket channel. Once the connection is open, requests and responses no longer need to be paired strictly. The server can send a message as soon as a new event happens, and the client can send user input back over the same connection immediately. Data travels as frames, and both text and binary payloads are supported. The important consequence is that the connection remains alive. The server must track which user is attached to which socket, and the client must handle reconnection and resynchronization after network interruptions. Real-time delivery is gained, but connection-state management becomes a new operational responsibility.

WebSocket and REST are alike in that both are channels for moving data between browser and server. But REST is a request-response model: the server only responds when a request arrives. WebSocket is a long-lived connection model where either side may send a message whenever needed. That means discrete operations like lookup and save remain simpler with REST and are easier to debug with standard HTTP tooling. By contrast, screens whose value depends on constant state changes are a better fit for WebSocket. The word 'real-time' alone is not enough to justify it; the deciding factors are change frequency and how much delay the user can tolerate.

WebSocket is strongest in products where the same screen stays open and the state changes frequently: chat, collaborative editing, live alerts, and operations dashboards. Sending events over an already-open connection is much more natural than issuing a fresh request for each tiny change. In practice, connection management matters more than the message format. You need a reconnection story when the browser tab is backgrounded or the network blips, a resync strategy for missed events, and a cleanup policy for stale connections on the server. There is also no reason to turn every API into WebSocket traffic. Authentication, initial data fetches, and one-off saves are often still simpler over HTTP. In many systems, WebSocket complements the existing HTTP surface rather than replacing it.