2000 年，Roy Thomas Fielding 博士在他那篇著名的博士论文《Architectural Styles and the Design of Network-based Software Architectures》中提出了几种软件应用的架构风格，REST 作为其中的一种架构风格在这篇论文的第5章中进行了概括性的介绍。

REST 是”REpresentational State Transfer”的缩写，可以翻译成”表现状态转换”，但是在绝大多数场合中我们只说 REST 或者 RESTful。Fielding 在论文中将 REST 定位为”分布式超媒体应用（Distributed Hypermedia System）”的架构风格，它在文中提到一个名为”HATEOAS（Hypermedia as the engine of application state）”的概念。

我们利用一个面向最终用户的 Web 应用来对这个概念进行简单阐述：这里所谓的应用状态（Application State）表示 Web 应用的客户端的状态，简单起见可以理解为会话状态。资源在浏览器中以超媒体的形式呈现，通过点击超媒体中的链接可以获取其它相关的资源或者对当前资源进行相应的处理，获取的资源或者针对资源处理的响应同样以超媒体的形式再次呈现在浏览器上。由此可见，超媒体成为了驱动客户端会话状态的转换的引擎。

借助于超媒体这种特殊的资源呈现方式，应用状态的转换体现为浏览器中呈现资源的转换。如果将超媒体进一步抽象成一般意义上的资源呈现（Representation ）方式，那么应用状态变成了可被呈现的状态（REpresentational State）。应用状态之间的转换就成了可被呈现的状态装换（REpresentational State Transfer），这就是 REST。

总结

REST 是一种很笼统的概念，它代表一种架构风格。

论文溯源讲清了 REST 的学术本义，但工程界说的”RESTful”早已是一组可执行的约束清单而非哲学。本文把两层打通：六大约束是什么、落到 API 设计上的具体规则、以及”伪 REST”的常见形态与 Richardson 成熟度分级。

六大约束（论文版）

  1. 客户端-服务器：职责分离，各自独立演进
  2. 无状态：请求自带全部上下文，服务器不存会话 → 可水平扩展、可重试
  3. 可缓存：响应显式声明可缓存性，客户端/中间层缓存降负载
  4. 统一接口：资源标识（URI）、资源表述（JSON/XML）、自描述消息、HATEOAS
  5. 分层系统：中间层（网关/缓存/代理）可插入，客户端无感知
  6. 按需代码（可选）：下发可执行代码（极少用）

工程上最常违反的是 2 与 4：服务器存会话破坏无状态；URI 动词化破坏统一接口。

工程落地规则（实践版）

  • 资源名词化：/orders/123 而非 /getOrder?id=123；集合用复数 /orders
  • 方法表意图：GET 读（安全幂等）、POST 创建（不幂等）、PUT 全量替换（幂等）、PATCH 局部更新、DELETE 删除（幂等）
  • 状态码表结果：200/201（Location 头）/204、400/401/403/404/409/422、500/503；业务错误放 body 的 code 字段，不滥用 200 包一切
  • 版本化：/v1/orders 或 Accept 头版本
  • 分页/过滤/排序：/orders?page=2&size=20&status=PAID&sort=createdAt,desc
  • HATEOAS 务实版：响应带相关链接（next/prev/self/actions），不追求完整超媒体驱动

Richardson 成熟度模型：你的 API 在第几级

  • Level 0：单一 URI + POST（RPC 套 HTTP 壳，”伪 REST”起点）
  • Level 1：资源 URI 分化
  • Level 2：HTTP 方法 + 状态码正确
  • Level 3：HATEOAS 超媒体链接

业界自称 RESTful 的多在 Level 2；达到 2 已能获得 REST 的主要工程收益（无状态扩展性、缓存、统一工具链），Level 3 按需追求。

伪 REST 的常见形态

  • /user/login、/user/logout 动词 URI（登录本质是”创建会话资源”，可 POST /sessions）
  • 全 POST + body 传操作名（Level 0）
  • 200 + {success:false} 表达一切错误（状态码语义丢失，缓存/网关/监控全部失效）
  • 服务器存 session 破坏无状态（与水平扩展直接冲突）

REST vs RPC vs GraphQL

  • REST：资源导向、缓存友好、浏览器/CDN 友好，适合开放 API 与 CRUD 主导场景
  • RPC（gRPC/Dubbo）：动作导向、强契约、高性能，适合内网服务间
  • GraphQL：客户端按需取数、单端点，适合前端聚合多源数据的场景

三者是接口建模视角的差异：资源、动作、查询图。选型的本质是问”我的消费者按什么心智访问系统”。

理解 RESTful 的完整答案 = 论文六约束（为什么）+ 工程规则（怎么做）+ 成熟度分级（做到哪）+ 伪 REST 识别（别做错）。四层齐备，”REST 是一种笼统的架构风格”这句总结才真正有了可操作的内涵。