Networking & HTTP
Web networking for front-end engineers — the HTTP request/response model, HTTP/2 multiplexing, and REST API design.
8 questions
JuniorTheoryVery commonWhat is REST, and how do CRUD operations map onto HTTP methods?
What is REST, and how do CRUD operations map onto HTTP methods?
REST is an architectural style for client–server APIs, not a protocol or standard: resources are identified by URLs and manipulated through a uniform set of HTTP methods. The CRUD operations map to methods as create → POST, read → GET, update → PUT/PATCH, delete → DELETE.
Common mistakes
- ✗Calling REST a protocol or standard rather than an architectural style
- ✗Using
GETto mutate data orPOSTfor every operation - ✗Thinking REST mandates JSON rather than being format-agnostic
Follow-up questions
- →Why is statelessness a core constraint of the REST style?
- →When would you choose
PATCHoverPUTfor an update?
JuniorTheoryCommonWhat is the structure of an HTTP request and response?
What is the structure of an HTTP request and response?
A request has a start line (method like GET/POST, path, version), headers (key–value metadata such as Host, Content-Type, Authorization), an empty line, and an optional body. A response has a status line (version, status code like 200/404, reason), headers (Content-Type, Set-Cookie, Cache-Control), the empty line, and the body. The method states intent; the status code states the outcome.
Common mistakes
- ✗Thinking
GETrequests carry a body or that bodies are mandatory - ✗Confusing the request method with the response status code
- ✗Believing headers exist only on responses, not requests
Follow-up questions
- →What do the status-code classes
2xx,3xx,4xx, and5xxeach mean? - →Why is
GETconsidered safe and idempotent whilePOSTis neither?
JuniorTheoryCommonWhat is a WebSocket, and how does its connection differ from HTTP?
What is a WebSocket, and how does its connection differ from HTTP?
A WebSocket is a protocol giving a persistent, full-duplex channel over one TCP connection, so client and server can push messages to each other at any time. It opens as an HTTP request with an Upgrade: websocket header; once accepted, it leaves the request/response model.
Common mistakes
- ✗Thinking a WebSocket is half-duplex or request/response like HTTP
- ✗Forgetting it begins with an HTTP upgrade handshake
- ✗Assuming each message opens a new connection rather than reusing one
Follow-up questions
- →Why does the WebSocket handshake reuse the HTTP
Upgrademechanism? - →When is plain HTTP polling preferable to a WebSocket?
MiddleTheoryCommonIn CORS, what is the difference between a simple request and a preflighted one?
In CORS, what is the difference between a simple request and a preflighted one?
A simple request (a GET/POST/HEAD with only safelisted headers and content types) is sent straight to the server; the browser then checks the Access-Control-Allow-Origin response header before exposing the body to the script. The server, not the browser, grants access.
Common mistakes
- ✗Thinking the browser, not the server, decides whether cross-origin access is allowed
- ✗Expecting a
PUTor custom-header request to skip theOPTIONSpreflight - ✗Believing
Access-Control-Allow-Originis sent by the client
Follow-up questions
- →What exactly turns a request from simple into preflighted?
- →How can a server cache a preflight result to avoid repeating
OPTIONS?
MiddleTheoryOccasionalHow does HTTP/2 differ from HTTP/1.1, and what is the front-end benefit?
How does HTTP/2 differ from HTTP/1.1, and what is the front-end benefit?
HTTP/2 uses a binary framing layer and multiplexes many concurrent requests and responses over a single TCP connection, removing HTTP/1.1's application-layer head-of-line blocking and the ~6-connection limit. It also compresses headers (HPACK). So domain sharding stops being useful.
Common mistakes
- ✗Thinking HTTP/2 opens more connections rather than multiplexing over one
- ✗Still using domain sharding or file concatenation under HTTP/2
- ✗Believing HTTP/2 switches the transport from TCP to UDP
Follow-up questions
- →Why does multiplexing remove HTTP/1.1's per-connection head-of-line blocking?
- →Why does domain sharding become an anti-pattern under HTTP/2?
MiddleDesignOccasionalA browser app relies on a WebSocket for live updates, but connections drop on flaky mobile networks, server restarts, and idle timeouts. Design a reconnection strategy on the client: how you detect a dropped connection, how you decide when to retry, how you avoid overwhelming the server when many clients reconnect at once, and how you restore application state after a successful reconnect. Note any limits of a naive fixed-interval retry.
A browser app relies on a WebSocket for live updates, but connections drop on flaky mobile networks, server restarts, and idle timeouts. Design a reconnection strategy on the client: how you detect a dropped connection, how you decide when to retry, how you avoid overwhelming the server when many clients reconnect at once, and how you restore application state after a successful reconnect. Note any limits of a naive fixed-interval retry.
Listen for the close/error event and start a reconnect loop. Use capped exponential backoff (1s, 2s, 4s … up to 30s) plus random jitter so thousands of clients do not reconnect in lockstep and stampede the server. Heartbeat frames catch a silently dead connection.
Common mistakes
- ✗Retrying on a fixed interval, causing a thundering-herd stampede on the server
- ✗Omitting jitter so all clients reconnect in lockstep
- ✗Forgetting to re-subscribe and resync state after a reconnect
Follow-up questions
- →Why does adding random jitter to backoff matter when many clients drop together?
- →How would a last-acknowledged message id let you replay only what was missed?
SeniorDesignOccasionalYou are building a browser app that opens a WebSocket to a backend that must only serve authenticated users. The browser WebSocket API does not let you set custom request headers such as Authorization, so the usual bearer-token-in-header approach is unavailable on the client. Design how you would authenticate and authorize the WebSocket connection: how the client proves identity at connect time, how the server enforces it, and how you would handle a token that expires while a long-lived connection is open. Explain the trade-offs of your chosen approach versus the alternatives.
You are building a browser app that opens a WebSocket to a backend that must only serve authenticated users. The browser WebSocket API does not let you set custom request headers such as Authorization, so the usual bearer-token-in-header approach is unavailable on the client. Design how you would authenticate and authorize the WebSocket connection: how the client proves identity at connect time, how the server enforces it, and how you would handle a token that expires while a long-lived connection is open. Explain the trade-offs of your chosen approach versus the alternatives.
Authenticate at the handshake: the server, which does see the HTTP upgrade request, validates an existing session cookie or a short-lived token passed via the connection URL (query param) or a subprotocol; reject the upgrade if invalid so unauthorized sockets never open.
Common mistakes
- ✗Assuming the browser WebSocket constructor can set an
Authorizationheader - ✗Treating the connection as authenticated forever and ignoring token expiry
- ✗Putting a long-lived token in the URL where it leaks into server logs
Follow-up questions
- →Why is a session cookie on the upgrade request vulnerable to CSRF without an origin check?
- →How would you re-authorize a connection whose token expires mid-session?
SeniorTheoryRareWhat is the REST maturity concept HATEOAS, and what does it add?
What is the REST maturity concept HATEOAS, and what does it add?
HATEOAS (Hypermedia As The Engine Of Application State) is the top level of REST maturity: each response embeds hypermedia links describing the actions available next, so the client discovers what it can do from the server's responses rather than hard-coding URLs.
Common mistakes
- ✗Hard-coding endpoint URLs in the client despite a hypermedia API
- ✗Confusing HATEOAS link-driven navigation with caching or auth
- ✗Thinking it makes the API more rigid rather than more evolvable
Follow-up questions
- →How does following links instead of URLs let the server evolve endpoints freely?
- →What is the minimum a HATEOAS client needs to know in advance?
