REST 的六大约束#

Fielding 给 REST 定了六条约束，满足这些的 API 才能叫 RESTful：

1. 客户端-服务器分离：前端只管 UI，后端只管数据，各自独立演进
2. 无状态：每个请求都包含所有必要信息，服务器不记「上次聊到哪了」
3. 可缓存：响应要标明自己能不能被缓存，减轻服务器压力
4. 统一接口：这是 REST 的灵魂——资源用 URL 标识、通过表示来操作资源、消息自描述、HATEOAS 超媒体驱动
5. 分层系统：客户端不知道自己是直接连服务器还是经过了代理/负载均衡
6. 按需代码（可选）：服务器可以下发可执行代码（比如 JavaScript）

资源导向设计#

REST 的核心思想是「一切皆资源」。设计 API 时，先想清楚有哪些实体：

1
GET    /articles          # 文章列表
2
GET    /articles/42       # 第42篇文章
3
POST   /articles          # 新建文章
4
PUT    /articles/42       # 整体更新
5
PATCH  /articles/42       # 部分更新
6
DELETE /articles/42       # 删除

注意：URL 用名词复数，动词用 HTTP 方法表达。千万不要写出 /getArticle?id=42 这样的 URL，那就不 REST 啦～

HTTP 状态码的正确姿势#

返回正确的状态码是 REST API 的基本素养：

• 200 OK — 一切顺利
• 201 Created — POST 创建成功
• 204 No Content — DELETE 成功，没有返回体
• 400 Bad Request — 客户端请求有问题
• 401 Unauthorized — 没登录
• 403 Forbidden — 没权限
• 404 Not Found — 资源不存在
• 500 Internal Server Error — 服务器崩了

不管出什么错，永远不要返回 200 + {"error": "xxx"}！ 这是最常见的反模式——错误信息应该用 4xx/5xx 状态码表达。

HATEOAS：REST 的最高境界#

HATEOAS（Hypermedia as the Engine of Application State）是 REST 里最容易被忽略的一条。它的意思是：API 响应里应该包含下一步可以做什么的链接：

1
{
2
  "id": 42,
3
  "title": "RESTful API 设计",
4
  "_links": {
5
    "self": "/articles/42",
6
    "author": "/users/7",
7
    "comments": "/articles/42/comments"
8
  }
9
}

这样一来，客户端不需要死记硬背 URL 结构——跟着链接走就行，就像浏览网页一样！不过说实话，真正实现 HATEOAS 的项目并不多，这也是为什么有人调侃「世界上 90% 的 REST API 其实只是 HTTP API」😂

写在最后#

REST 不是什么高深的黑魔法，它是一套让 API 设计变得自然、可预测、易于维护的哲学。下次设计接口的时候，不妨问问自己：URL 里是不是只有名词？状态码用得对不对？响应里有没有告诉客户端下一步去哪？如果能答上这三个问题，你的 API 就已经很 RESTful 啦 💕

好啦～今天的科技小课堂就到这里！宝贝们还想听什么？GraphQL 和 REST 的对比？还是 gRPC？评论区告诉窝～ 🎀✨