HTTP Fundamentals
The problem
Once two programs can exchange raw bytes over TCP, they still need to agree on what those bytes mean — a shared, structured way to say 'give me this resource' or 'here's the resource you asked for, and here's whether it worked.' HTTP is that shared vocabulary for the web.
Why now
TCP and DNS solve delivery and addressing, but neither says anything about the content of the conversation. HTTP is the application-layer protocol that finally gives the bytes meaning — a request with a method and path, a response with a status and body — built on top of everything below it.
Mental model
HTTP is a strict request/response exchange: a client sends a method (what it wants to do — GET, POST) and a path (what it wants to do it to), and a server replies with a status code (did it work, and in what way) plus a body. It's deliberately stateless — each request stands alone, which is simple and scalable, but means anything resembling 'session' has to be bolted on top (cookies, tokens).
Requires
- TCP & UDPNetworking
HTTP is built on top of TCP, relying on its reliable, ordered delivery guarantee to make sense of a request and response as complete, in-order messages.
- DNSNetworking
An HTTP request begins with resolving the target host's name to an IP address; DNS is the step that makes 'GET https://example.com/' addressable at all.
Unlocks
Used in
- Every web page load, REST API call, and most inter-service communication
- HTTP status codes as a universal vocabulary for success/failure/redirection across the entire web
- Caching, authentication, and content negotiation, all built on HTTP headers
- GraphQL, gRPC, and WebSockets, which layer on top of or alongside HTTP
Projects
- Use curl -v to make a raw HTTP request and read the full request and response, including headers
- Build a minimal HTTP server from scratch (without a framework) that responds correctly to GET requests with the right status codes
Examples
- GET /users/42 asks for a resource; a 200 status with a JSON body means success, a 404 means it doesn't exist
- HTTP's statelessness is why every request typically carries its own auth token — the server doesn't remember you between requests
Resources
Mastery checklist
- I can explain the parts of an HTTP request and response (method, path, headers, status, body)
- I can name the major HTTP status code categories (2xx, 3xx, 4xx, 5xx) and what each means
- I can explain what 'HTTP is stateless' means and how sessions are built on top of it anyway
- I can use curl to inspect a raw HTTP exchange and interpret every part of it