什么是 HATEOAS 和 Richardson Maturity Model？

Question

IT Interview Practice · Accepted Answer

**Richardson Maturity Model（RMM）** 用四个级别给一个 API 有多“RESTful”评分，而 **HATEOAS** 是最高级别——大多数人跳过的那个约束。

## 四个级别

```text
Level 0 — "The Swamp of POX": one URI, one method (RPC over HTTP).
          POST /api  { "action": "getUser", "id": 42 }
Level 1 — Resources: many URIs, but still one verb.
          POST /users/42  ,  POST /users/42/delete
Level 2 — HTTP Verbs: proper methods + status codes (where most "REST" APIs live).
          GET /users/42 → 200 ,  DELETE /users/42 → 204
Level 3 — Hypermedia Controls (HATEOAS): responses link to what you can do next.
```

大多数生产环境的“REST”API 都在 **Level 2**——正确的资源、method 和 status code。这通常已经足够好，并且是一个完全合理的目标。

## HATEOAS（Level 3）

**HATEOAS** = *Hypermedia As The Engine Of Application State*。核心思想：一个 response 包含若干**link**，告诉 client 接下来有哪些动作可用，因此 client 通过跟随 link 来导航 API，而不是硬编码 URL——就像人跟随网页上的 link，而不去记住每一个 URL。

```http
GET /orders/1001 HTTP/1.1
```
```http
HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 1001,
  "status": "pending",
  "total": 250,
  "_links": {
    "self":   { "href": "/orders/1001" },
    "pay":    { "href": "/orders/1001/payment", "method": "POST" },
    "cancel": { "href": "/orders/1001/cancel",  "method": "POST" }
  }
}
```

因为这个 order 是 `pending`，server 提供 `pay` 和 `cancel` link。一旦付款完成，那些 link 就消失，可能出现一个 `refund` link——**server 驱动状态转移**，而 client 只跟随给它的任何 link。

## 为什么它很罕见

它承诺的是解耦：client 不硬编码 URL，因此 server 可以自由地重组它们。实践中大多数 client 无论如何都硬编码，HATEOAS 增加了真实的复杂性，而格式从未完全标准化（HAL、JSON:API、Siren 相互竞争）。回报很少能抵得上成本。

## 为什么这很重要

这是一道经典的 senior 级题目，因为它把**按最初定义理解 REST**的人，与那些宽松地用“REST”来表示“JSON over HTTP”的人区分开来。有价值的洞见不是背诵这四个级别——而是那种判断力：能说出**Level 2 是实用主义的甜蜜点**，同时知道真正的 REST（Fielding 的定义）*要求* HATEOAS，并能解释*为什么业界大多忽略它*：解耦收益是真实的，但很少被实现，因为 client 反正会硬编码 URL，而增加的复杂性加上相互竞争的 hypermedia 格式，对典型 API 并不划算。表明你知道 HATEOAS *是什么*、能给出一个具体的状态驱动 link 的示例、并能就成本/收益诚实地论辩——而不是教条地坚持每个 API 都必须是 Level 3——正是面试官在探寻的那种平衡的、基于经验的判断力。

四个级别

HATEOAS（Level 3）

为什么它很罕见

为什么这很重要

相关问题