HTTP

The Hypertext Transfer Protocol (HTTP) is the application-layer protocol that governs communication between clients and servers on the World Wide Web. It is a request-response protocol: a client sends a request message to a server, which processes the request and returns a response message. Despite its apparent simplicity — the entire protocol can be summarized in a few pages of specification — HTTP is the substrate on which the modern internet is built, and its design decisions encode a particular theory of how distributed systems should coordinate.

Stateless Architecture and the Simplicity Illusion

HTTP is fundamentally stateless: each request from client to server must contain all the information necessary to understand and fulfill it, and the server retains no memory of previous requests from the same client. This design choice, made by Tim Berners-Lee in 1991, was not an oversight but a deliberate simplification. Statelessness means that any server can handle any request, enabling horizontal scaling, load balancing, and fault tolerance by treating servers as interchangeable.

But the simplicity is illusory. Real web applications require state — shopping carts, authentication sessions, user preferences. HTTP's statelessness merely pushes the complexity of state management to other layers: cookies (state stored on the client), sessions (state stored in a database or cache), and tokens (state encoded in cryptographically signed strings). The protocol's elegance is achieved by exporting its messiness upward and outward, into the application layer and the infrastructure layer.

This pattern — local simplicity purchased at the cost of global complexity — is characteristic of successful distributed protocols. The Internet protocol suite operates on the same principle: routers are simple because the complexity of reliable delivery is pushed to the endpoints. HTTP extends this logic to the application layer, making the web server a dumb pipe and the browser a smart endpoint.

From Documents to APIs: The Protocol's Evolution

HTTP was originally designed for transferring hypertext documents — HTML pages with embedded links. The methods were simple: GET to retrieve a resource, POST to submit a form. But the protocol's flexibility — its use of MIME types to describe content, its extensible header mechanism, its separation of resource identification (the URL) from resource representation (the response body) — made it suitable for far more than document transfer.

The emergence of RESTful architecture in the early 2000s formalized this evolution. Roy Fielding's doctoral dissertation showed that the existing HTTP methods — GET, POST, PUT, DELETE — could be interpreted as the operations of a uniform interface for manipulating resources. A GET request is idempotent and safe; a POST request is neither. These constraints are not arbitrary; they enable caching, proxying, and retry semantics that make the web scalable. The protocol's success as an API substrate is not despite its limitations but because of them.

The contemporary web is dominated by protocols that extend or replace HTTP for specific use cases: WebSockets for bidirectional streaming, gRPC for high-performance internal services, GraphQL for flexible querying. Yet HTTP remains the universal fallback — the protocol of last resort that every system must speak, because it is the one protocol guaranteed to traverse firewalls, proxies, and corporate networks.

HTTP as a Model of Distributed Coordination

HTTP encodes a particular philosophy of distributed systems: clients are active, servers are reactive; requests are short-lived, responses are self-contained; failure is handled by retry, not by complex recovery protocols. This philosophy is not universal. In a message-passing system, both parties might be active. In a consensus protocol, all nodes are symmetric. HTTP's asymmetry — client-initiated, server-response — reflects the web's origins in document retrieval, but it has shaped how we think about service-oriented architecture more broadly.

The protocol's handling of failure is particularly revealing. HTTP defines status codes — 200 for success, 404 for not found, 500 for server error, 503 for service unavailable — that create a shared vocabulary for describing failure modes. But these codes are advisory, not enforceable. A server that returns 200 while serving corrupted data is not violating the protocol; it is violating the contract that the application layer has built on top of the protocol. HTTP provides the syntax of coordination; the semantics are negotiated separately.

HTTP is often described as the foundation of the web, but this metaphor misleads. A foundation supports a building; HTTP is more like the road network that connects buildings. And like a road network, its design shapes what can be built: the statelessness, the request-response asymmetry, the text-based headers, the extensibility mechanism — each of these is a design choice that enables some architectures and forecloses others. The web we have is not an inevitable consequence of digital networking. It is a consequence of HTTP. A different protocol — more stateful, more symmetric, more structured — would have produced a different internet, with different power structures, different business models, and different forms of social coordination. The protocol is not neutral infrastructure. It is architecture, and architecture is politics encoded in packet headers.