Web development series—HTTP basics

Every web application you’ve ever built runs on three things: a protocol, a server, and a client. Developers spend most of their time thinking about the server and occasionally the client. The protocol—HTTP—tends to get treated as plumbing. It’s there, it works, you don’t think about it. That’s fine until something goes wrong, or until you need to build something that requires actually understanding how the communication layer behaves.

HTTP stands for Hypertext Transfer Protocol. Tim Berners-Lee designed it as part of the original web architecture, and RFC 2616 remains the canonical specification. The model is simple: a client (usually a browser) sends a request, a server sends a response. That request-response cycle is the fundamental unit of all web communication.

Statelessness—the design decision that shapes everything

The most important thing to understand about HTTP is that it’s stateless. The protocol doesn’t retain any information about previous requests. Each request is independent. The server receives a request, processes it, returns a response, and forgets the exchange happened.

This was a deliberate design choice, and it has significant implications. It makes HTTP simple and scalable—servers don’t need to maintain per-connection state across millions of concurrent users. But it means that anything requiring continuity across requests—user sessions, shopping carts, authentication—has to be managed at the application layer, not the protocol layer.

Every mechanism you’ve used for state management (cookies, session tokens, server-side session stores) exists because of this fundamental characteristic. Understanding that HTTP itself is stateless clarifies why those mechanisms work the way they do and what their limitations are.

Status codes—the protocol’s vocabulary of outcomes

When a server responds to a request, it includes a three-digit status code that tells the client what happened. These codes are organized into five classes, and understanding the classes gives you a mental map before you memorize individual codes.

The 1xx range is informational—the server acknowledging receipt and indicating the request is still in progress. You’ll rarely see these in application code. The 2xx range signals success. 200 OK is the one you want most of the time. The 3xx range covers redirection—the resource has moved, either permanently (301) or temporarily (302), and the client should look elsewhere. The 4xx range indicates client errors: the request was malformed (400), unauthorized (401), or asked for something that doesn’t exist (404). The 5xx range is server errors—something went wrong on the server’s end that the client couldn’t have anticipated.

Getting these ranges into muscle memory is useful because they appear everywhere in debugging, monitoring, and logging. A spike in 5xx responses means something is broken server-side. A surge in 4xx responses might mean a deployment broke client-side request construction, or an API contract changed without updating callers.

Going deeper

HTTP is specified in RFC 2616, maintained by W3C, and well-documented across a range of resources including the Wikipedia HTTP article and the HTTP pipelining spec for those interested in the performance optimization layer. Room 404—a site dedicated to HTTP—is also worth a look.

This is a protocol that rewards understanding. The more web development you do, the more often you’ll find yourself wanting a mental model that goes beyond “the browser sends stuff and the server replies.”