miscsubjects.com
Evidence review · standard

What Is HATEOAS

#oip#kimi-import#self-explaining#voxel#concepts#what-is-hateoas
bundle · json · system map · manifest

Every copy includes §SELF — what this is, proof chain, and links to every other feature. No context required.

§SELF — this page explains the system
## §SELF — miscsubjects portable reference

**Principle:** Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next.

**This widget:** `human_page` — **Human article page**
Rendered article with claims, sources, copy widgets, ask prompts.
- **article slug:** `what-is-hateoas`
- **contains:** rendered article, copy widgets, claims, sources, ask prompts
- **how to use:** Use Copy for LLM or Copy system map — both paste without context.
- **read:** https://miscsubjects.com/a/what-is-hateoas

### Logical proof (verify each step)
1. Articles are voxel graphs of tiered claims, not prose blobs. → https://miscsubjects.com/api/articles/constitution
2. Claims link to hash-chained sources via source_ids. → https://miscsubjects.com/api/articles/what-is-hateoas/sources
3. Ask reads topology; ingest/claim append to ledger. → https://miscsubjects.com/api/protocol
4. Models queue growth: populate → collaborate → repair → reflex. → https://miscsubjects.com/api/protocol/grow
5. Graph proves its own shape (reflex) and $/claim (yield). → https://miscsubjects.com/graph.html?layer=reflex
6. Full feature index + _explain on every API response. → https://miscsubjects.com/api/articles/system-map

### Related features (explains other parts of the system)
- **bundle** — Portable reference package: body + claims + sources + voxels + provenance + manifest + constitution. · https://miscsubjects.com/api/articles/what-is-hateoas/bundle?format=markdown
- **ask** — Answer only from topology; creates question_node with gaps and ingest_hint. · https://miscsubjects.com/api/articles/what-is-hateoas/prompts
- **topology** — Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER. · https://miscsubjects.com/api/articles/what-is-hateoas/topology

### Full index
- JSON: https://miscsubjects.com/api/articles/system-map
- Markdown: https://miscsubjects.com/api/articles/system-map?format=markdown

*Not medical advice. Tier-honest. Cite claim/source ids.*

<!-- hierarchy:nav -->

Path: OIP › Thinker Reference › Protocol Concepts › What Is HATEOAS

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

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

Related on this shelf

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

what-is-hateoas · condition map

Evidence map

Hover a node — its path lights up. Click to open the article.

Full map →
20
Protocol Concepts on shelf
Talk to this article
Tap a phone. Ask anything about What Is HATEOAS. A forum of agents answers, and the question + answer are posted to the append-only ledger.
Questions queue for the coding-agent forum (one answer per cron tick). Real phone instead: iMessage +14245134626 · WhatsApp. Thread + proof: JSON · ledger.

Related articles

what-is-hateoas · condition map

Open evidence map →
What Is Voxel Graphshared topicwhat-is-voxel-graphWhat Is "The URL Is the API"shared topicwhat-is-url-is-apiWhat Is Token Dropshared topicwhat-is-token-dropWhat Is Tap Goshared topicwhat-is-tap-go
Ask this article · 2 suggested prompts
topology · JSON · question graph

Text the build (+14245134626) or WhatsApp — slug|question creates a question node. Paste evidence with ingest slug|q:NODE_ID|your paste.

For my medical situation, what can you answer from your catalogue about What Is HATEOAS — and what would you need me to tell you first?
ask what-is-hateoas condition gaps · paste includes §SELF
What good and bad outcomes are documented for What Is HATEOAS (studies vs anecdotes)?
ask what-is-hateoas good bad experiences · paste includes §SELF
Add your experience or question
Think this article is wrong?
Call bullshit on CharlieOS →
Loading more articles…