The World Wide Web

Summary#

The World Wide Web was proposed by Tim Berners-Lee at CERN in March 1989, in a memo titled Information Management: A Proposal. The proposal picked three pieces and put them together: a way to name documents (URIs), a way to fetch them (HTTP), and a way to format them with links to other documents (HTML). The first web page went live in December 1990. Mosaic, the first popular graphical browser, shipped in 1993. By 1995 the Web had effectively absorbed every other Internet information system — Gopher, WAIS, Archie, FTP-as-document-store — and become the default substrate for everything that talks across the Internet.

The Web is not the Internet. The Internet is the IP-and-TCP substrate; the Web is one application running on top of it. Other applications (email, DNS, SSH, NTP, BitTorrent) run over the same Internet without going through the Web. But the Web’s three components — URI, HTTP, HTML — became so universally adopted that for most of the 2010s and 2020s, “an API” effectively meant “an HTTP API addressed by URLs returning structured data,” and the conventions of REST (resources, verbs, status codes, hypermedia) are direct descendants of what Berners-Lee picked.

For an API designer, the Web is the cultural and technical inheritance you stand on. URLs you design follow the URI syntax Berners-Lee defined. Status codes you return are HTTP’s. Caching semantics you rely on are HTTP’s. The reason your API is https://api.example.com/v1/users/42 instead of users@example.com:42 is that the URL form won — and you should know why.

Why it matters#

Three reasons the Web’s design choices still cast a shadow over every API written today.

• The Web’s defaults are your API’s defaults. A REST API uses URLs because the Web used URLs. It uses HTTP verbs because the Web’s verbs were good enough. It uses status codes because the Web’s status codes are universally understood. Every API designer inherits a vocabulary that pre-dates them by three decades.
• The Web’s architecture is REST’s architecture. Roy Fielding’s 2000 dissertation, which named REST, was an after-the-fact description of why the Web’s HTTP architecture worked — statelessness, uniform interface, cacheability, layering. REST is “the Web, formalised.” Designing a RESTful API is, in large part, repeating the Web’s architectural commitments at the API scale.
• The Web is the longest-running successful distributed system. Components in the Web ecosystem evolve independently: browsers (Chrome ships every six weeks) and servers (Apache, nginx) and proxies and CDNs all interoperate despite being built by different teams over different decades. The architectural property that makes this work — backwards-compatible, additive evolution of the contract — is what every long-lived API aspires to.

The Web is the proof-of-concept that a well-designed contract can outlive every implementation behind it. HTTP/0.9 from 1991 was a single-line request returning HTML; HTTP/3 from 2022 runs over QUIC over UDP and handles concurrent streams. The contract evolved over 30 years without ever breaking the universe of clients.

How it works#

The Web has three components, each underpinned by a small set of design decisions that turned out to matter.

URIs — uniform resource identifiers#

A URI is a string that names something. The form is a scheme, an authority, a path, and optional query and fragment:

https://api.stripe.com/v1/charges?limit=10#section
└─┬─┘   └─────┬─────┘└────┬────┘└────┬────┘└──┬──┘
scheme    authority      path      query   fragment

The genius of the URI is that it is a global namespace partitioned by authority. The stripe.com part says: “Stripe owns this name; ask them what’s behind it.” Stripe owns its piece, you own yours, no central registry has to coordinate the next path segment. The same partitioning that makes DNS work makes URLs work. New schemes (mailto:, tel:, ipfs:, data:) can be added without changing anything else.

A URL is a URI that also tells you how to fetch the thing. Most APIs deal in URLs because the consumer needs to act on them; pure URIs (identifier without retrieval method) come up rarely outside semantic-web contexts.

The path part is the API designer’s playground. /v1/charges/ch_abc123 is a URL the integrator reads and predicts. That predictability is the entire point: a well-named URL is its own documentation.

HTTP — hypertext transfer protocol#

HTTP is a request-response protocol with verbs, headers, a body, and status codes. The original 1991 version had one verb (GET) and returned HTML. By HTTP/1.1 in 1997, the protocol had eight verbs, status codes grouped into 1xx/2xx/3xx/4xx/5xx ranges, persistent connections, content negotiation, and conditional requests. By HTTP/2 in 2015, it had multiplexed streams and header compression. By HTTP/3 in 2022, it had moved off TCP to QUIC over UDP. The contract — verbs, headers, status codes — barely changed across all three.

The properties HTTP locked in that REST later named:

• Stateless requests — every request carries everything the server needs. No session state on the server beyond what the client re-sends. This is what makes horizontal scaling trivial — any server can serve any request.
• Uniform interface — a small fixed set of verbs (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS) plus a standard envelope (headers, body, status). New resources do not need new verbs.
• Cacheability — responses self-describe their cacheability via headers (Cache-Control, ETag, Last-Modified). Intermediaries (browser cache, CDN, proxy) can cache without coordinating with the origin.
• Layered system — clients cannot tell if they are talking to the origin or to a chain of proxies. This is what makes CDNs possible.

These four properties are the load-bearing parts of REST. Every other REST principle (HATEOAS, code-on-demand) is a footnote next to them.

HTML — hypertext markup language#

HTML is the document format that the Web’s pages are written in. For API designers, HTML matters less directly — most APIs return JSON, not HTML — but the design idea HTML introduced is the link. An HTML document references other documents by URL, and the browser follows them. That hypertext idea, that documents can name and reference each other in a single global namespace, is the conceptual core of the Web.

The API analogue is hypermedia: a response that includes URLs to related resources. A GET /orders/123 response that includes "customer_url": "/customers/45" is hypermedia. Fully hypermedia-driven APIs (HATEOAS in REST jargon) are rare in practice, but the principle — that responses self-describe how to navigate from one resource to the next — shows up in pagination cursors, related-resource links, and OpenAPI’s links object.

Why these three won#

The Internet of the 1980s had many competing information systems. Gopher had a menu-driven interface. WAIS had full-text search. FTP had directory listings. Each was good at one thing. The Web was good at one thing too: linking. A Gopher menu could not reference a WAIS document; a WAIS result could not link to an FTP file. The Web’s URLs could name any of them, and HTML’s <a href> could link to anything that had a URL. The composability of “everything has a URL, links are hypertext” was the network effect that ate the others.

The lesson for API designers: a composable contract beats a powerful one. The Web’s verbs were less expressive than RPC; its formats were less rigid than schema-first protocols; its caching was less precise than custom invalidation. It won anyway because anything with a URL could be referenced from anything else.

Variants and trade-offs#

The Web’s three-piece foundation has competitors that lost — and the reasons they lost are worth knowing.

Later challengers to the Web’s API role have come and gone. SOAP (1998) added XML envelopes and WS-* standards on top of HTTP, and lost to plain REST because the overhead did not pay for itself. CORBA (1991) and Java RMI (1997) tried object-oriented remoting and never escaped intra-organisation use. Newer styles — GraphQL (2015), gRPC (2016) — have not displaced REST; they coexist as specialised tools for specific niches (client-flexible data shaping; high-throughput typed RPC). The Web’s three-piece architecture has remained the default substrate for public APIs for over two decades.

When this is asked in interviews#

The Web rarely comes up by name in an API-design round, but Web-level architectural literacy shows up in several specific moments.

The first is the statelessness discussion. The interviewer asks “how do you scale this horizontally?” The senior answer leans on HTTP’s stateless property — any server can serve any request because the request carries everything needed. The junior answer adds a sticky session and hopes the load balancer keeps the user pinned. The senior answer is the Web’s answer; the junior answer is the pre-Web answer.

The second is the caching question. “How would you cache this endpoint?” The right answer names Cache-Control, ETag, Vary, the CDN layer, and the difference between public and private caching. All of these are HTTP primitives that the Web’s architecture mandated and that the rest of the industry inherited.

The third is the versioning question. “How does this API evolve?” The Web’s answer is “additive evolution, with backwards-compatible defaults, and never a flag day.” Every well-aged API — Stripe’s, AWS’s, GitHub’s — has followed this discipline. Candidates who propose v2/v3/v4 endpoints, each duplicating the last, are working against the Web’s architectural grain.

The summary line: the Web is the longest-running successful distributed contract. The properties that made it work — global names, stateless requests, cacheable responses, additive evolution — are the properties your API should aim for too.

Related concepts#

• The Narrow Waist of the Internet — the IP substrate the Web runs over, not to be confused with the Web itself.
• HTTP — The Foundational Protocol for APIs — the protocol Berners-Lee picked, modernised across HTTP/1.1, HTTP/2, and HTTP/3.
• REST — The Architectural Style — Fielding’s after-the-fact formalisation of what the Web got right.
• RESTful API Design in Practice — applying those properties to a modern resource-shaped API.
• What Is API Design? — the contract framing the Web’s architecture exemplifies.