How HTTP Actually Works
Every Web Request Is a Question and an Answer
Underneath every API call, page load, and fetch() is the same basic exchange: a client sends a request (a method, a URL, some headers, maybe a body), and a server sends back a response (a status code, headers, maybe a body). Everything else - REST, GraphQL, whatever framework you're using - is built on top of this one pattern.
GET /users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOi...
Accept: application/json
--- response ---
HTTP/1.1 200 OK
Content-Type: application/json
{"id": 42, "name": "Ada"}Status codes carry real meaning worth actually knowing: 2xx is success, 3xx is redirection, 4xx means the CLIENT did something wrong (404 not found, 401 unauthenticated, 403 unauthorized, 400 bad request), 5xx means the SERVER did something wrong. Returning 200 with an error message in the body - instead of an honest 4xx or 5xx - is a common anti-pattern that makes debugging and monitoring harder for everyone downstream.
Headers carry metadata separate from the actual content: `Content-Type` tells the receiver how to parse the body, `Authorization` carries credentials, `Cache-Control` tells browsers and CDNs how long they're allowed to reuse a response instead of asking again. None of this is visible in the response body itself - it's worth knowing to look at headers, not just the JSON, when something's behaving oddly.