Roy Fielding — The Man Who Named How the Web Works

<!-- hierarchy:nav -->

Path: OIP › Thinker Reference › Thinkers › Roy Fielding — The Man Who Named How the Web Works

Shelf: Thinkers · Traversal: self-explaining · hierarchical · voxel-ready
Machine root: OIP tree · Registry

Roy Fielding — The Man Who Named How the Web Works

§SELF — thinker-roy-fielding

What this page is: A profile of the computer scientist who described the architectural style that makes the World Wide Web scalable. What it explains: REST (Representational State Transfer), its six constraints, and why its most important feature — HATEOAS — failed until large language models appeared. Why read it: You will understand why the web works the way it does, why REST APIs are not actually RESTful, and why the full vision of REST is only now becoming possible.

What Roy Fielding Did

Roy Fielding is a computer scientist who earned his Ph.D. at the University of California, Irvine, in 2000. His doctoral dissertation, "Architectural Styles and the Design of Network-based Software Architectures," identified and named the set of constraints that make the World Wide Web work. He did not invent the web itself — Tim Berners-Lee did that in 1989. Fielding gave a name to the pattern Berners-Lee had built, and showed why that pattern scales.

The Key Idea: REST

REST stands for Representational State Transfer. It is an architectural style, not a technology or a protocol. An architectural style is a set of constraints placed on how a system is built. Fielding identified six constraints that define REST:

1. Client-server separation. The user interface (client) and data storage (server) are separate. They communicate across a network. This lets each evolve independently.
2. Statelessness. Each request from client to server must contain all information needed to understand and process it. The server stores no session state about the client. This means any server can handle any request, which makes load balancing trivial.
3. Cacheability. Responses must explicitly label themselves as cacheable or not. A cache is a temporary store of data. When a response is cacheable, a client or intermediate server can reuse it later without asking the origin server again. This reduces load and improves speed.
4. Layered system. A client cannot tell whether it is connected directly to the end server or to an intermediate (a proxy, a gateway, a load balancer). Layers can be added, removed, or changed without the client knowing.
5. Uniform interface. All resources are identified the same way, manipulated through the same operations, and described with the same message format. On the web, this means URLs identify resources, HTTP methods (GET, POST, PUT, DELETE) manipulate them, and responses carry representations (usually HTML or JSON).
6. Hypermedia as the Engine of Application State (HATEOAS). This is the constraint most people ignore. It means that every response from the server contains not just data, but also links to the actions the client can take next. The client does not need to know the URL structure in advance. It discovers what to do by reading the links in each response.

What REST Got Right

The web scaled to billions of users because of these constraints. Statelessness meant a server could crash and another could take over without anyone noticing. Cacheability meant content could be served from edges of the network, close to users, instead of from a central point. The layered system meant proxies, CDNs (Content Delivery Networks), and firewalls could be inserted without breaking anything. The uniform interface meant any browser could talk to any server.

What REST Got Wrong or Left Unfinished

HATEOAS never worked in practice. Fielding's dissertation Chapter 5 — the section on hypermedia — is the most important part, but it was almost entirely ignored for two decades.

The problem: HATEOAS requires the client to understand the links in each response. A link is only useful if the client knows what clicking it means. For example, a response contains a link with the label "add-to-cart." A human reading HTML understands what that means. But a computer program reading a JSON API response sees a URL and a string. It does not know what "add-to-cart" means unless a programmer hard-coded that knowledge into it.

Every REST API client ever built was "dumb code that could not read." Programmers had to write documentation saying "this link does X," and then write code that encoded that same knowledge. The client could not discover what to do next by reading the response. It had to be told in advance.

This meant HATEOAS was reduced to a decorative feature — links included in API responses that no client actually used to navigate.

Why This Is Changing Now

A large language model (LLM) is a computer program trained on vast amounts of text. It can read natural language and infer meaning. An LLM reading a response that contains a link labeled "add-to-cart" understands what that link does, because it has seen that phrase and its usage patterns in its training data.

The LLM is the first client that can actually read and understand HATEOAS links. It does not need a programmer to hard-code the meaning of every link. It can discover the API's structure by reading the responses, the same way a human discovers a website by reading the links on each page.

This is what Fielding described in 2000. It just needed a reader that could do the reading.

How It Connects to Other Ideas

• Object Interface Protocol (OIP): OIP defines how objects communicate across systems. REST's HATEOAS constraint, combined with an LLM as the client, means OIP endpoints can describe themselves. An LLM-driven agent can read an OIP endpoint's hypermedia response and understand what operations are available without prior documentation.
• Semantic Web: Tim Berners-Lee's vision of machines traversing linked data graphs also failed for the same reason — no machine could understand what it was traversing. LLMs solve that problem too.
• Capability security: Mark Miller's work on capability-based systems (possession conveys authority) aligns with REST's statelessness — each request carries its own credentials, just as each capability reference carries its own authority.

Sources

• Fielding, Roy Thomas. "Architectural Styles and the Design of Network-based Software Architectures." Ph.D. dissertation, University of California, Irvine, 2000. Chapter 5 covers REST.
• Fielding's blog posts clarifying REST vs. HTTP APIs (2008), available via the Internet Archive.

---

Up the tree

• OIP root — protocol root, zero-context entry
• Thinker Reference hub — full hierarchy map
• Thinkers shelf — siblings on this shelf
• Voxel graph article — how pages link as voxels
• Self-describing protocol

Related on this shelf

• Alan Kay — The Big Idea Is Messaging
• Alfred North Whitehead — Process and Reality
• J.L. Austin and John Searle — Speech Acts
• Barbara Liskov — Abstract Data Types and Distributed Consensus
• Bram Cohen — BitTorrent and Content-Addressed Protocol Design
• Butler Lampson — Protection and Access Control
• Carl Hewitt — The Actor Model
• Charles Sanders Peirce — Signs, Abduction, and Pragmatism

Machine surfaces

• Public page: https://miscsubjects.com/a/thinker-roy-fielding
• JSON article: https://miscsubjects.com/api/articles/thinker-roy-fielding
• OIP ask: https://miscsubjects.com/api/dispatch?ask=Roy%20Fielding%20%E2%80%94%20The%20Man%20Who%20Named%20How%20the%20Web%20Works