Backend & Data
REST vs WebSockets: letters vs a phone call
When your app needs to talk to a server, you usually reach for one of two patterns. REST is like posting a letter and waiting for the reply. A WebSocket is like ringing someone up and leaving the line open. Knowing which is which saves you a lot of pain.
REST — send a letter, get a reply
With REST, the client asks a question, the server answers, and the exchange is done. Each request stands alone: "give me this user," "save this order." It's simple, cacheable, and scales beautifully. The catch: the server can't speak unless spoken to. If you want to know when something changes, you have to keep asking — a habit called polling, which is wasteful if updates are rare and laggy if they're frequent.
WebSockets — keep the line open
A WebSocket opens a single, long-lived connection that stays put. Once it's up, either side can send a message whenever it wants, with almost no overhead per message. That's exactly what you want for live data: chat messages, notifications, a ticking price feed, a collaborative document, a dashboard that updates itself.
One question, one answer, then you're done → REST. A continuous, two-way, low-latency stream of updates → WebSockets.
In practice, you'll use both
This isn't a cage match. Most real apps mix them: REST for ordinary actions (log in, fetch a page, save a form) and a WebSocket for the live layer on top. A trading dashboard is the classic example — REST to pull your account and place an order, a WebSocket to stream quotes that flicker in real time. Pick the tool that matches the shape of the conversation, and don't be surprised when the answer is "both."