Networking & HTTP
All front-to-back communication runs over HTTP — a (conceptually) text request/response protocol on top of TCP. REST APIs rest on it, CORS negotiates cross-site requests over it, and WebSocket departs from the request/response model toward a persistent two-way channel.
The thread running through the topic is the request/response model and its limits. HTTP is by nature stateless and one-directional: the client asks, the server answers. Protocol versions speed this model up (multiplexing), REST structures it, CORS protects it, and WebSocket outgrows it. Each layer below unpacks one of these mechanisms.
Topic map
- The HTTP protocol — the structure of a request and response, methods, status codes, headers.
- HTTP versions — HTTP/1.1 vs HTTP/2, multiplexing, and the end of domain sharding.
- REST APIs — the architectural style, resources by URL, and mapping CRUD onto methods.
- The REST style — the REST constraints, idempotency, maturity levels, and HATEOAS.
- CORS — a simple vs a preflighted request, and why the server grants access.
- WebSocket — a persistent two-way channel, the upgrade, authentication, and reconnection.
Common traps
| Mistake | Consequence |
|---|---|
| Thinking CORS is blocked by the browser "itself" | The server grants access via Access-Control-Allow-Origin; the browser only enforces it |
Treating GET as fine for changing data | GET must be safe and idempotent; changes go through POST/PUT/PATCH/DELETE |
Confusing PUT and PATCH | PUT replaces the whole resource (idempotent), PATCH changes part |
| Calling REST a protocol | REST is an architectural style on top of HTTP, not a standard or a protocol |
| Opening a WebSocket where one request would do | A persistent channel is justified only for frequent two-way exchange |
Trying to set Authorization on a browser WebSocket | The client WebSocket API allows no custom headers — authenticate at the handshake |
| Reconnecting a WebSocket at a fixed interval | Thousands of clients hit the server at once; use exponential backoff with jitter |
Interview relevance
Networking is asked to check whether you understand what happens between fetch and the response. A candidate who says "CORS is a server permission, not a browser ban" immediately shows they debugged real cross-site requests rather than googling "how to disable CORS".
Typical checks:
- The structure of a request and response, the meaning of methods and status codes.
- What HTTP/2 delivered — multiplexing — and why domain sharding is no longer needed.
- Mapping CRUD onto methods and the difference between
PUT/PATCH. - Who grants cross-site access in CORS and how, and what a preflight is.
- How WebSocket differs from HTTP and how to authenticate it.
Common wrong answer: "you need to disable CORS on the front end". CORS is not configured on the client at all — the cross-site read is granted by the server via Access-Control-Allow-Origin; the browser merely applies that decision.