1.1 什么是 REST：契约精神的源头

1.1 什么是 REST：契约精神的源头

本节摘要：REST（表现层状态转移）不是协议、不是标准、更不是"用 GET 加 JSON 的接口"，而是一种架构风格。它由 Roy Fielding 在 2000 年博士论文中提出，核心命题是把网络上的信息抽象为"资源"，通过"表示"在客户端与服务器之间传递状态。理解这一点，是理解后面所有 URI、方法、缓存条款的前提。

学习目标

阅读完本节，你应当能够：

1. 区分"架构风格""协议""技术栈"三个词，并准确说出 REST 属于哪一类。
2. 解释"表现层状态转移"六个字的字面含义与它要解决的核心问题。
3. 说清"资源"与"资源表示"的区别，并各举一例。
4. 识别并反驳"REST 必须返回 JSON"这类常见混淆。

一、为什么先较真这个词

与其直给定义，不如先说清楚一个行业里几乎人手一份的误会：REST 到底是不是 JSON 接口的代名词。

打开任何一个招聘 JD，十有八九写着"负责 RESTful API 设计与实现"，配图往往是一张 GET 请求加一个 JSON 返回。久而久之，"REST"在许多人头脑里就简化成一个标签：只要我用 GET、POST、DELETE，返回 JSON，就算 RESTful。这个简化在面试够用，在工程里却会掩盖一个大问题——你不知道这份契约到底承诺了什么、放弃了什么。

契约的精神，恰恰是先搞清楚"我在签什么"。所以这一节我们先不赶进度，把两个字拆到最底层。

二、REST 的准确定位

REST 的全称是 Representational State Transfer，直译是"表现层状态转移"。把它和几种近邻词摆在同一张桌子上，界限立刻清楚：

REST 属于最左边那一列：它是一组约束，教你怎么把系统切成资源并按统一规则交互，但它不规定你用哪种语言、哪种字节格式、哪种传输方式。你可以用 HTTP 实现 REST，理论上也能用别的东西实现它。

"Representational State Transfer"里藏着全部心法。拆开看：

• Resource（资源）：任何能命名的概念，一个用户、一张订单、一篇博客，是一个抽象名词。
• Representation（表示）：资源在某个时刻的具体样子，比如那份 JSON 就是"用户资源"的一种表示。
• State Transfer（状态转移）：客户端用请求表示自己想要的下一步，服务器返回资源的最新表示，应用的状态就这样从服务器"转移"到客户端。

一句话：客户端不直接操作资源本身，而是操作资源的表示，读取它、改它、再传回去。

三、资源和表示，容易混又关键

把同一个用户资源 JSON 打印两份，内容字段一模一样，但它们是不是同一个"资源"？

不是。它们是同一个资源的两种表示，正如打印在纸上的合同和存进系统的电子合同，都不是"要约"本身，只是它的承载形式。资源是一个抽象的、可以命名的概念；表示是它此刻的具体编码。这个区分不是咬文嚼字——它正是第 2 章谈"通过表示操作资源"、第 4 章谈"序列化格式协商"的理论地基。

举个顺手能验证的例子。设计一个书店接口，URI 路径 /book/42 指代"第 42 书本资源"。同一个 URI，用带 Accept: application/json 的请求可能拿到 JSON，换成 Accept: application/xml 可能拿到 XML。URI 没变，资源没变，变的是返回的表示。如果你把"资源"和"表示"看成同一回事，就说不清这个现象，也谈不上设计内容协商。

{
  "id": 42,
  "title": "设计中的设计",
  "author": "小七",
  "pages": 240
}
​

上面这段 JSON 是"书资源 42"的一种表示。它携带的信息足够服务器在后续 PUT 时重建这份资源。

用一张词义拆解图收住"资源与表示"这对最难的概念：

图：资源与表示两个视角

四、Fielding 设计 REST 时在对抗什么

2000 年 Fielding 写论文的语境是：万维网已经跑起来，但对"为什么它伸缩得这么好、这么容易演进"缺乏一个正式的架构解释。REST 是他给网做的一次"蓝图复盘"，反过来也成了后续所有 Web API 的母本。

REST 的核心动机是最大化共享、最小化耦合。它希望：任何客户端拿着统一规则就能操作任何资源（共享统一接口）；同时服务器改内部实现、加新资源，客户端不用跟着改（耦合最小）。这两件事在无约束的设计里天然打架——你给了客户端便利，就绑死了服务器。REST 用一组约束把它们调和到一个平衡点。

五、一个经典的识别练习

判断下面这些做法的"REST 纯度"：

1. 只发 GET，返回 JSON，能查出数据。→ 只碰到了 REST 的皮毛。
2. 用 /getAllUsers 这种动词 URI。→ 违反方法语义，把动词写进了资源路径。
3. 用 /users/123 拿资源，再响应里带 _links 告诉客户端下一步去哪。→ 靠近 HATEOAS，是接近正统 REST 的做法。

第一条是最容易被误判"算 RESTful"的。事实是："能发请求 + 能回 JSON"只是 HTTP 交互，离 REST 的统一接口约束还差着距离。判定真伪的标准，是它有没有老老实实遵守五条硬约束，尤其是资源识别、通过表示操作、自描述消息——这些会逐一在后续章节展开。

⚠️ 常见坑：在技术评审里把"REST 化"简化成"格式化成 JSON"。真正改架构时，这会让本该做资源建模的环节被跳过，最后交付的只是"套着 JSON 壳的 RPC"。

💡 关键直觉：记住"资源是一种抽象、表示是它的壳、状态通过表示转移"，这一句能解释后面至少八成的设计决策。

FAQ：RPC 和 REST 的关系

RPC 把网络调用伪装成"直接调一个函数"，REST 把它变成"操作一份资源"。两者不是优劣关系，是取舍关系，第 1.3 节会展开。这里只需记住：REST 站在"资源"肩上诉求长期演进而非单次效率。

交付前把要点钉在图纸上

• 要点一：REST 是架构风格，不是协议、不是技术栈、不等于 JSON 接口。
• 要点二："表现层状态转移"指通过资源表示在客户端与服务器间传递应用状态。
• 要点三：资源是抽象名词，表示是它当下的具体编码，两者必须分清。
• 要点四：REST 用约束换共享与低耦合，核心动机是最大化共享、最小化耦合。
• 要点五：只发 GET 加 JSON 不算真 RESTful，要看是否遵守五条硬约束。
• 要点六：判定 REST 纯度靠约束而非格式，这是贯穿全册的仲裁尺。

下一节我们把 Fielding 的六大约束摊开，逐一划出哪些是铁律、哪条可以省略。

把"REST 是架构风格"这个判断钉进图纸，是后续所有节的共同前提；一旦把它误当成"JSON 接口"，后面谈方法语义、谈资源建模就会滑回 RPC 的老路。