RESTful API

REST 的六个约束

Fielding 定义了六个约束，只有全部满足才算 REST（不满足的通常叫「类 REST」）：客户端-服务器分离、无状态、可缓存、统一接口、分层系统、按需代码（可选）。实际工程中，「统一接口」是最重要也最常被忽视的：资源通过 URI 标识（/users/123），通过 HTTP 方法操作（GET 查、POST 建、PUT 替换、PATCH 更新、DELETE 删除），表示与操作解耦。

Richardson 成熟度模型把 API 分为 0-3 级：Level 0 是用 HTTP 做 RPC（一个 URL，全走 POST）；Level 1 引入资源；Level 2 用 HTTP 动词；Level 3 引入超媒体控件（HATEOAS）。真正的 Level 3 REST 在工业界罕见，大多数号称「REST」的 API 只达到 Level 2。[1]

REST 与 GraphQL、gRPC 的比较

REST 在过度获取（Over-fetching）和获取不足（Under-fetching）上有天然缺陷：GET /users/123 可能返回几十个字段，而前端只需要名字和头像。Facebook 为此于 2015 年开源了 GraphQL，让客户端精确声明所需字段，一次查询跨多个资源——代价是缓存变复杂，服务端需要处理任意查询组合的性能风险。

gRPC（谷歌 2015 年开源）走另一条路：用 Protocol Buffers 做接口定义和序列化，基于 HTTP/2，强类型、高性能，适合微服务内部通信，但浏览器原生支持受限（需要 gRPC-Web 代理）。REST 在公开 API 领域仍占主导，更多是因为其普适性和工具链成熟，而非技术上的绝对优势。