1. RESTful API 概述：什么是REST、RESTful API的六大约束、RESTful API的优势与适用场景

1.1 什么是REST？先从一个故事说起

我记得刚入行那会儿，团队里讨论接口设计，大家各说各的。有人用 /getUser?id=1，有人用 /user/query?type=1，还有人直接 POST 一个 JSON 过去让后端自己猜意图。那叫一个乱。

后来我接触到 REST，才明白原来接口设计是有「章法」的。

REST 的全称是 Representational State Transfer，中文叫「表现层状态转移」。名字听着玄乎，说白了就是：把后端资源抽象成 URL，用 HTTP 方法去操作它。

举个例子：

// 不 REST 的风格
POST /api/getUser
POST /api/deleteUser
POST /api/updateUser

// RESTful 风格
GET    /api/users/1      // 获取用户
DELETE /api/users/1      // 删除用户
PUT    /api/users/1      // 更新用户

你看，同样的资源 /api/users/1，用不同的 HTTP 方法表达不同的操作。这就是 REST 最核心的思想。

1.2 RESTful API 的六大约束

REST 有六个约束条件。少一个，就不能叫严格的 RESTful API。我在项目中见过不少「自称 RESTful 但实际只满足两三条」的接口，嗯，这里要注意区分。

约束一：客户端-服务器（Client-Server）

这个好理解。前端只管展示，后端只管存数据。各司其职，互不干扰。我见过有人把业务逻辑写在 SQL 里，也有人把渲染逻辑塞进后端接口——都是坑。

约束二：无状态（Stateless）

每个请求必须包含所有必要信息。服务器不存客户端上下文。

约束三：可缓存（Cacheable）

响应要明确标注是否可缓存。用 Cache-Control、ETag 这些头信息告诉客户端：「这个数据你可以存多久」。

约束四：统一接口（Uniform Interface）

这是最核心的约束。包含四点：

• 资源标识：每个资源有唯一 URL
• 通过表现操作资源：客户端拿到的是资源的「表现」，比如 JSON
• 自描述消息：每个请求/响应都包含足够信息让对方理解
• HATEOAS：响应里包含下一步可做的操作链接（这个很多项目做不到，但它是 REST 的终极形态）

约束五：分层系统（Layered System）

客户端不知道它直接连的是最终服务器还是中间代理。你可以加负载均衡、加缓存层、加网关，客户端完全无感知。

约束六：按需代码（Code on Demand，可选）

服务器可以给客户端返回可执行脚本（比如 JavaScript）。这个约束是可选的，实际用得少。

约束	是否必须	我的经验
客户端-服务器	必须	基本所有 Web 项目都满足
无状态	必须	最容易踩坑的地方
可缓存	必须	很多人忽略，但性能提升明显
统一接口	必须	REST 的灵魂所在
分层系统	必须	微服务架构天然满足
按需代码	可选	我几乎没用过

1.3 RESTful API 的优势

你想想看，为什么 REST 能火这么多年？我个人觉得有这几个原因：

• 简单直观：URL 就是资源，HTTP 方法就是操作。新人上手快。
• 无状态带来高可扩展性：服务器不用记 Session，随便加节点。
• 缓存友好：利用 HTTP 本身的缓存机制，性能提升立竿见影。
• 语言无关：不管前端用 React、Vue 还是 iOS、Android，都能调。
• 生态成熟：各种工具、框架、文档生成器都支持。

1.4 适用场景与不适用场景

REST 不是万能的。我见过有人非要用 REST 做实时推送，结果搞出一堆轮询代码，又丑又慢。

适合用 REST 的场景：

• CRUD 为主的业务系统（用户管理、订单、商品）
• 移动端 API
• 开放 API（给第三方开发者调用）
• 微服务之间的同步调用

不太适合的场景：

• 实时通信（用 WebSocket 更合适）
• 高频小数据交互（用 gRPC 性能更好）
• 复杂查询和报表（用 GraphQL 更灵活）

好了，这一章我们聊了 REST 是什么、六个约束、优势和场景。下一章我会带你手写第一个 RESTful API，从设计 URL 到实现代码，咱们一步步来。