WebSocket vs HTTP for Persistent API Connections
Persistence in an API connection isn't one thing. It runs on a range, from "close the connection the second we're done" all the way to "keep this pipe open forever and shove data through it whenever." WebSocket and HTTP sit at different points on that range, and picking between them comes down to three things: how your traffic moves, how fast it needs to move, and how much pain your team can stomach on the ops side.
HTTP started out stateless on purpose, and every request stands alone; the server forgets you the moment it answers. HTTP/1.1 added keep-alive, which reuses the same TCP connection for multiple requests, but the ask-and-wait rhythm never really goes away: you ask, it answers, you ask again. WebSocket, defined in RFC 6455, works differently from the ground up. It starts as a normal HTTP request, gets upgraded with a 101 Switching Protocols response, and then the TCP connection just stays open, with frames flowing in both directions whenever either side has something to say, no more asking and waiting.
HTTP persistence reuses a pipe, while WebSocket persistence throws out the request-response pattern entirely. That's the difference worth holding onto, and it's why the shape of your traffic, not habit or whatever's trending on Hacker News, should decide which one you reach for.
The overhead gap that makes WebSocket fast for sustained traffic and irrelevant for sparse traffic
Start with the raw numbers. A WebSocket frame adds somewhere between 2 and 14 bytes of overhead, while an HTTP request, headers and all, typically runs 500 to 2,000 bytes. Separately, the ratio of WebSocket headers to HTTP headers has been measured at 1:245.
On paper, WebSocket wins every time. In practice, both protocols pay the same toll up front: a TCP handshake, then a TLS handshake if you're on HTTPS (which, in 2026, you should be). If you're firing off one request, or ten spread across a day, that handshake cost eats whatever savings you'd get from smaller frames. The overhead gap only shows up once messages get small, frequent, and don't stop.
Think about what that means for actual API design. A REST endpoint that fires once per form submission or once per page load never gets near the volume where framing overhead matters; the handshake dominates no matter which protocol you picked. But a live multiplayer cursor feed, a stock ticker, a collaborative doc pushing dozens of tiny updates a second? That's where 1:245 stops being trivia and starts showing up in your latency budget and your bandwidth bill.
Throughput is only one axis, though. Which direction the data flows, whether any of it can be cached, how much weight your team can carry, all of that is still open.
How traffic direction determines whether WebSocket is necessary or over-engineered
Most things people call "real-time" only need data moving one way: server to client. Dashboards, notification feeds, log tails, AI chat responses streaming word by word — none of that needs the client talking back mid-stream, so treating it like a two-way problem solves something nobody asked about.
That's the gap Server-Sent Events fills. SSE runs over plain HTTP, pushes data in one direction, and carries lower per-message overhead than WebSocket, while connection state stays minimal too. Latency-wise, SSE and WebSocket both operate in the millisecond range, with WebSocket edging it out, but that edge only matters for things like multiplayer games or two people editing the same paragraph at once. For a notification badge or a streaming chat reply, the difference is a rounding error.
Look at what the big AI labs actually shipped for their completion APIs. The major AI labs use SSE for streaming responses, not WebSocket, and that's not an oversight. It's teams looking at their traffic pattern, seeing it runs one direction, and picking the simpler tool.
WebSocket earns its keep once the client is also talking, and talking often: chat apps, multiplayer games, collaborative editing. Slack, Discord, Figma's multi-cursor view, Google Docs co-editing, Linear's sync engine all clear that bar, though most apps never do.
HTTP/1.1 capped how many connections a browser could hold open per domain to a small number, which made running several concurrent SSE streams painful. HTTP/2 multiplexes many streams over one connection, and that per-domain ceiling mostly disappears. This sets up a fairly clean upgrade path: polling, then SSE, then WebSocket, each step justified only by a specific limit the one before it couldn't clear.
What HTTP/2 and HTTP/3 actually change — and what they don't
HTTP/2 brought multiplexing, header compression, and got rid of the per-domain connection cap. That's what fixed SSE's old scaling problem and made HTTP streaming usable in ways it wasn't before.
Something HTTP/2 didn't touch: WebSocket is still the only way to get full-duplex, truly bidirectional communication in a browser, as Ably pointed out back in 2024. A spec exists for running WebSocket over HTTP/2 (RFC 8441), so the two aren't enemies, though it hasn't seen widespread uptake.
HTTP/3, built on QUIC, fixes something structural: TCP's head-of-line blocking, where one dropped packet stalls every frame behind it on the same connection. That's a real weak spot for WebSocket, since it rides on TCP underneath. A spec exists for WebSocket over HTTP/3 too (RFC 9220), but as of early 2026, no major browser or server ships it in production, so it lives on paper more than in practice.
Then there's WebTransport, built directly on HTTP/3 and QUIC, supporting multiple multiplexed streams plus unreliable datagrams (meaning it's fine to drop a packet instead of retransmitting it, which is exactly what fast-twitch games and live video want). It's closer to what low-latency developers actually wish they had. Browser support still lags well behind WebSocket's near-universal coverage as of mid-2026, though.
HTTP's ceiling keeps climbing, while WebSocket's ceiling is boxed in by TCP itself — and that ceiling still sits far higher than almost anything most apps will ever need to hit.
The scalability gap that HTTP teams rarely anticipate before they've committed
Here's the asymmetry that bites teams late. HTTP is stateless, so any server behind your load balancer can answer any request. WebSocket is stateful: once a client connects to a specific server, it's stuck there, because that server is the one holding the open socket.
That single fact drags in a pile of infrastructure you didn't have before: sticky sessions on your load balancer, plus a shared message bus (something like Redis, Kafka, or NATS) so a message meant for a connection on Server B can get routed there even when it originates on Server A. None of that exists in a stateless HTTP world, and none of it is optional once you're stateful.
Raw connection counts can trick you too. With proper tuning, a single server can hold upward of half a million idle WebSocket connections. But idle connections are a memory bill, not a CPU bill; push a burst of messages across all of them at once and CPU and bandwidth get hit instantly and at the same time. Every one of those connections is also usually running a ping/pong heartbeat just to stay alive — tiny per connection, but collectively it represents continuous packet load once you're at scale.
Cloud pricing makes the tradeoff concrete instead of abstract. AWS charges its Application Load Balancer per active connection, so at high concurrency you're paying a real fixed cost before a single message crosses the wire. API Gateway's WebSocket support charges per connection-minute and per message, and those costs stack up fast enough that teams often migrate off it as concurrent connections climb.
HTTP skips all of this. Stateless requests get load-balanced and scaled horizontally without a second thought, and they cache cleanly; none of the backplane complexity applies. The real question isn't whether WebSocket can technically handle your load; it's what running WebSocket at your projected scale actually costs, in dollars and in engineering hours, before you've written a line of business logic.
Security exposures that are specific to WebSocket and don't follow from HTTP assumptions
Browsers enforce same-origin policy on XHR and fetch calls, but they don't enforce it on WebSocket upgrade requests. That gap alone is the root of Cross-Site WebSocket Hijacking, or CSWSH.
Here's how it plays out: a malicious page opens a WebSocket connection to your server, riding on the victim's existing cookies. If your server doesn't check the Origin header, the attacker gets a live, two-way connection into your system using someone else's identity. That's worse than CSRF, which only ever runs one direction, and it's significant enough to have its own entry in the CWE catalog (CWE-1385) — a known, named category of weakness, not some edge case somebody made up to sound smart.
Default behavior makes this worse than it needs to be. Popular libraries, the Node.js ws package among them, don't validate Origin out of the box. Teams have to bolt that check on themselves, and plenty don't realize they need to until something's already gone wrong.
Authentication doesn't carry over cleanly either. WebSocket has no built-in auth mechanism of its own. Tokens get passed during the handshake, and if you're not careful, those tokens keep working long after the session they were meant for should've expired, which means you need explicit rotation logic that a stateless HTTP API never has to think about.
Logging has a blind spot too. Standard HTTP logs capture the initial upgrade request and then go dark; every message sent after that over the open connection is invisible to tooling built around HTTP access logs. Recognized WebSocket threat categories include CSWSH, auth bypass, payload injection (XSS, SQL injection riding in through message content), connection-exhaustion denial of service, and these monitoring gaps.
Fixing the biggest one is simple to state, even if it's not always simple to enforce: validate the Origin header on every handshake, reject anything from an origin you don't trust. That single check closes the CSWSH hole. WebSocket still needs its own security work, though, built on purpose, not inherited from whatever's already protecting your HTTP endpoints. Budget for that before you commit to the protocol, not after you've shipped and someone else finds the hole for you.
A decision framework built on traffic pattern, latency tolerance, and operational overhead
Three questions settle this. Which direction does the data move, and how often: client to server only, server to client only, or genuinely both, constantly? How much latency can the app tolerate: sub-10ms and interactive, low-single-digit-ms and collaborative, or is a few seconds fine? And how much operational weight can the team actually carry: stateful infrastructure, security hardening, fleet costs at scale?
HTTP, on HTTP/2 or HTTP/3, wins when requests are sparse, cacheable, or triggered by a specific user action. Think standard REST APIs, asset delivery, login flows. It wins for teams who want horizontal scaling without standing up a pub/sub backplane, and it wins anywhere caching is doing real work for you, since WebSocket has no caching layer at all, full stop.
SSE wins for server-to-client streaming: AI completions, live dashboards, notification feeds, tailing logs in real time. If your infrastructure already runs HTTP/2, SSE gets you real-time push without taking on WebSocket's operational weight.
WebSocket wins when the interaction is genuinely bidirectional, high-frequency, and latency-sensitive: collaborative editing, multiplayer games, trading interfaces where a millisecond is money. It's the right call for teams willing to build sticky sessions, run a pub/sub backplane, harden the security gaps above, and keep a token-rotation policy alive.
Most production systems don't pick just one, though. The common pattern is a hybrid: REST or HTTP handles setup, auth, anything cacheable, while WebSocket or SSE handles only the live-data channel. Each layer does the job it's actually good at instead of one protocol pretending it can do everything.
One thing worth watching: WebTransport, built on HTTP/3 and QUIC, is designed to address WebSocket's TCP head-of-line-blocking problem and adds unreliable datagrams, exactly what a lot of low-latency use cases want. Browser support still trails WebSocket's near-universal coverage as of mid-2026, so WebSocket stays the default for new bidirectional work today. That'll shift eventually, just not yet, and probably not on the timeline anyone building a roadmap right now is hoping for.
Map how your data actually moves before you touch a protocol spec. Everything else, the framework, the cost math, the security checklist, only makes sense once you know that.
