I get why this question keeps coming up. A WebSocket stays open, remembers who you are, and lets the server push data to you without you asking for it again and again. So why are we still firing off a hundred separate HTTP requests for a single page load when we could just open one persistent pipe and be done with it? Honestly, the question sounds smarter than most people give it credit for — and the answer is not “because HTTP is better.” It’s a lot more nuanced than that.
I kept hearing “use WebSockets for real-time stuff” without anyone explaining what actually happens on the wire. So I went and read the RFC, poked at a few servers, and figured I’d write down what I found — including the part that confused me the most: whether WebSocket is a protocol of its own or just some clever trick on top of HTTP.
So what is a WebSocket? A WebSocket is a persistent, full-duplex communication channel between a browser (or any client) and a server, opened over a single TCP connection [1]. Full-duplex means both sides can send messages whenever they want — not just in response to a request. That’s the part that breaks the usual mental model of the web.
Every request you make to a website carries a small pile of metadata you never see. Headers. They decide whether your connection is encrypted, whether a page can be embedded in an iframe, which CDN edge served you, and whether the browser should remember a cookie for a year. I wanted to see what a real, busy production site sends, so I pointed curl at an Amazon endpoint and dumped the response headers. Turns out there’s a lot to unpack.
Everyone slaps “RESTful” on their API. Open any docs page, scroll the marketing copy, and there it is — “our clean, RESTful API.” But here’s the uncomfortable bit: by the strict definition, almost none of them actually are. So the question you’re really asking is whether the word still means anything if you break some of the rules. Honestly, that’s where it gets tricky.
Short answer first, because I hate articles that bury it: yes, you can still call it RESTful in everyday conversation, but no, it isn’t a REST API by Roy Fielding’s original definition unless it’s hypertext-driven. Both of those things are true at the same time, and the gap between them is the whole story.