---
slug: what-is-hateoas
title: What Is HATEOAS
canonical: https://miscsubjects.com/a/what-is-hateoas
---

<!-- hierarchy:nav -->
> **Path:** [OIP](https://miscsubjects.com/a/oip) › [Thinker Reference](https://miscsubjects.com/a/oip-thinker-reference) › [Protocol Concepts](https://miscsubjects.com/a/oip-protocol-concepts) › **What Is HATEOAS**
>
> **Shelf:** Protocol Concepts · **Traversal:** self-explaining · hierarchical · voxel-ready
> **Machine root:** [OIP tree](https://miscsubjects.com/api/dispatch?map=1&format=markdown) · [Registry](https://miscsubjects.com/api/dispatch?registry=1)

# What Is HATEOAS

## §SELF — what-is-hateoas

**What this page is:** A definition of HATEOAS and an explanation of why it failed for 20 years and why it works now.
**What it explains:** The concept of hypermedia-driven application state and how the emergence of language models makes it practically usable for the first time.
**Why read it:** To understand why a long-neglected REST constraint is now relevant, and how it enables systems where clients discover actions dynamically rather than being hardcoded to fixed API endpoints.

### What HATEOAS Is

HATEOAS stands for "Hypermedia as the Engine of Application State." The term was coined by Roy Fielding in Chapter 5 of his 2000 doctoral dissertation, which defined the REST (Representational State Transfer) architectural style.

The core idea: every response from a server contains not only the requested data but also links that describe what actions are possible next. The client does not need prior knowledge of the API structure, endpoint URLs, or available operations. It reads the response, finds the links, and decides which to follow. The application's state is advanced entirely by the hypermedia (links) returned by the server — hence "the engine of application state."

Example: a client requests a user resource. The server responds with the user's data plus links: `"edit": "/users/42/edit"`, `"delete": "/users/42"`, `"orders": "/users/42/orders"`. The client reads these links and knows what it can do next. If the server removes the delete link, the client knows deletion is no longer an option. The client did not need to check a specification document. The response told it everything.

### Why It Matters

HATEOAS decouples the client from the server's API structure. The server can change URLs, add operations, or remove operations without breaking clients. Clients written to follow links adapt automatically. In a non-HATEOAS API, a URL change breaks every hardcoded client. In a HATEOAS API, the server changes its response, and clients follow the new links without modification.

This matters for long-lived systems where APIs evolve. It also matters for systems where clients need to navigate complex or variable workflows (multi-step processes, conditional paths, state-dependent options) without being programmed for every possible path in advance.

### The Key Idea

The server's response is self-describing. It contains both data and controls. The client discovers actions at runtime, not at compile time.

Fielding's REST dissertation specified this as a constraint: a RESTful application must be driven by hypermedia. A server returning JSON data alone is not HATEOAS. A server returning JSON data plus links to related actions and resources is HATEOAS.

The client needs no API specification (no OpenAPI document, no Swagger file, no documentation). The response itself specifies the available state transitions. This is how the World Wide Web works for humans: a web page contains links. You read the page, see the links, and click one. You did not need a manual to know what links a page would contain.

### What It Got Right

- **Runtime discovery of API capabilities.** Clients adapt to API changes without code modification. This reduces coupling between client and server.
- **Self-documenting responses.** Each response carries its own instructions for what can happen next. No external documentation is needed to navigate the API.
- **State-appropriate controls.** The server can include or exclude links based on the current state. A resource in a non-deletable state simply omits the delete link. The client does not need conditional logic to know what is allowed — the server tells it.

### What It Got Wrong or Left Unfinished

- **Traditional clients cannot read links and decide what to do.** Web browsers can do this for HTML — they render links for humans to click. But programmatic clients (scripts, mobile apps, backend services) are hardcoded to specific URLs and HTTP methods. They cannot parse a JSON response, discover links, and autonomously select an action. They need a human programmer to write that logic.
- **No machine-readable semantics for links.** Even if a client finds a link labeled `"edit"`, it does not know what HTTP method to use, what parameters to send, or what the action does without a specification. HTML has semantic conventions (`<a>` for GET, `<form>` for POST with fields). JSON link formats (RFC 5988, JSON Hyper-Schema, HAL) attempted to add semantics but never achieved wide adoption.
- **It failed for 20 years because the reader did not exist.** HATEOAS required a client that could read a response, understand the meaning of embedded links, and make decisions about which to follow. Traditional software cannot do this. A human reading HTML in a browser can, but programmatic APIs are designed for deterministic, pre-coded clients.

### How It Connects to Other Ideas

- **REST architecture:** HATEOAS is one of the architectural constraints that Fielding defined for REST, alongside statelessness, cacheability, and a uniform interface. Most APIs described as "RESTful" implement only the other constraints and omit HATEOAS.
- **Language models (LLMs):** A language model can read a response, identify links, understand their semantic labels, and decide which link to follow based on a goal. This capability did not exist when HATEOAS was specified. It exists now. HATEOAS was a protocol waiting for a reader. The reader has arrived.

### Sources

- Fielding, Roy Thomas. "Architectural Styles and the Design of Network-based Software Architectures." Doctoral dissertation, University of California, Irvine, 2000. Chapter 5: Representational State Transfer (REST).
- RFC 5988: Web Linking (IETF, 2010).

---

## Up the tree

- [OIP root](https://miscsubjects.com/a/oip) — protocol root, zero-context entry
- [Thinker Reference hub](https://miscsubjects.com/a/oip-thinker-reference) — full hierarchy map
- [Protocol Concepts shelf](https://miscsubjects.com/a/oip-protocol-concepts) — siblings on this shelf
- [Voxel graph article](https://miscsubjects.com/a/what-is-voxel-graph) — how pages link as voxels
- [Self-describing protocol](https://miscsubjects.com/a/what-is-self-describing-protocol)

## Related on this shelf

- [What Is Autopoiesis](https://miscsubjects.com/a/what-is-autopoiesis)
- [What Is Capability-Based Security](https://miscsubjects.com/a/what-is-capability-security)
- [What Is a Capability Token](https://miscsubjects.com/a/what-is-capability-token)
- [What Is a Confused Deputy](https://miscsubjects.com/a/what-is-confused-deputy)
- [What Is Context as Cursor](https://miscsubjects.com/a/what-is-context-as-cursor)
- [What Is a Convergence Catalogue](https://miscsubjects.com/a/what-is-convergence-catalogue)
- [What Is a Falsification Surface](https://miscsubjects.com/a/what-is-falsification-surface)
- [What Is the History of Link Protocols](https://miscsubjects.com/a/what-is-link-protocol-history)

## Machine surfaces

- Public page: `https://miscsubjects.com/a/what-is-hateoas`
- JSON article: `https://miscsubjects.com/api/articles/what-is-hateoas`
- OIP ask: `https://miscsubjects.com/api/dispatch?ask=What%20Is%20HATEOAS`


---

## Where OIP does this differently (required edge)

OIP difference: affordances are computed for the credential; omitted moves are denied by the server, not by documentation prose.

