HTTP — requests, responses, and headers

Strip away every library and framework, and an HTTP request is literally this, sent as plain text over an already-open TCP connection:

And the response, the exact same shape back:

Every REST API, every fetch() call, every browser page load reduces to exactly this: a start line, headers, a blank line, then an optional body. curl -v shows you this literal exchange for any real request, headers and all — genuinely worth running once against a real API to see it directly instead of only through a library's abstraction.

The GET-never-changes-state rule is a real contract, not a suggestion — browsers prefetch GET requests, proxies cache GET responses, and retry logic assumes GET is always safe to repeat. A GET endpoint that deletes data on the server violates that contract and will eventually break in a way that's genuinely hard to trace back to "someone's cache prefetched a delete."

The 4xx/5xx line matters more than it looks: a 4xx means the client should change something before retrying (fix the request, log in, use a valid ID) — a 5xx means the client did nothing wrong, the server itself failed, and a plain retry might actually succeed. Client code that blindly retries every failure the same way, or that never retries anything, is missing this distinction.

A handful you'll see constantly:

Each HTTP request is independent — the server keeps no memory of a previous request from the same client unless the client explicitly resends identifying information (a cookie, a token in Authorization) every single time. This is deliberate: because no server-side session state is required between requests, any request can be routed to any server behind a load balancer, and any server can be added, removed, or restarted without breaking anyone's "session" — a property distributed systems depend on constantly, covered directly in the System Design domain.

An operation is idempotent if doing it once and doing it five times produce the same end state. PUT /users/42 {"name": "Ada"} is idempotent — repeating it just sets the same name again. POST /orders typically isn't — repeating it naively creates five orders. This distinction is exactly why retry logic needs to know which method it's retrying: safely auto-retrying a failed GET or PUT is usually fine; auto-retrying a failed POST without an idempotency key can duplicate real side effects (charging a card twice is the classic example, and comes up directly again in the Payments & Financial Systems domain).