1. RESTful API 概述：什么是REST、RESTful API的六大约束、RESTful API的优势与适用场景
1.1 什么是REST？先聊聊我的理解
REST，全称是Representational State Transfer，翻译过来叫「表述性状态转移」。名字挺拗口，对吧？
我第一次接触这个概念时，也被这串英文搞懵了。后来做项目多了，慢慢就悟了——REST其实就是一套关于如何设计网络接口的规范。它告诉你，客户端和服务器之间该怎么「说话」，资源该怎么「表示」，状态该怎么「传递」。
打个比方。你去图书馆借书，你不需要知道书放在哪个架子的第几排，你只需要告诉管理员「我要借《Python编程》」，管理员就会把书给你。REST API也是这个道理——客户端只需要告诉服务器「我要获取用户ID为123的信息」，服务器就返回对应的数据。至于服务器内部怎么查数据库、怎么组装数据，客户端一概不管。
我个人习惯把REST理解为「面向资源的API设计风格」。资源就是你的数据实体，比如用户、订单、商品。每个资源都有一个唯一的URL标识，通过HTTP的GET、POST、PUT、DELETE这些方法来操作。
1.2 RESTful API的六大约束
说到RESTful API，就绕不开Roy Fielding博士在2000年提出的六大约束。这些约束是REST架构的基石。我在项目中见过不少自称「RESTful」的API，其实连一半都没做到。
下面我逐一拆解这六大约束，每个都附上我的实战体会。
约束一：客户端-服务器分离
说白了，前端和后端各干各的。客户端只管展示和交互，服务器只管存数据和业务逻辑。这样两边可以独立演进，互不干扰。
我曾经接手过一个老项目，前端代码里直接嵌了数据库查询语句。那叫一个酸爽——改个字段名，前端后端都得动。后来重构时，我硬是把它拆成了纯RESTful架构，前端只调API，后端只暴露接口。维护成本直接降了一半。
约束二：无状态
每个请求都是独立的，服务器不保存客户端的状态。你想想看，每次请求都得带上所有必要的信息，比如认证令牌、会话ID。服务器收到请求就处理，处理完就忘掉。
嗯，这里要注意。无状态不是说你的应用不能有状态，而是说状态要存在客户端。比如用户登录状态，客户端存个token，每次请求都带着。服务器验证token有效就放行，不记录「这个用户登录了没」。
约束三：可缓存
响应数据要明确标注是否可缓存。能缓存的就缓存，不能缓存的就不缓存。这样可以减少重复请求，提升性能。
实现方式很简单——用HTTP的Cache-Control、Expires这些头信息。比如用户头像这种不常变的数据，我一般设置缓存7天。但像订单状态这种实时数据，就设置no-cache。
约束四：统一接口
这是RESTful API最核心的约束。它要求接口设计遵循统一的规范，包括：
- 资源标识：每个资源有唯一的URL，比如/users/123
- 资源操作：用HTTP方法表示操作，GET查、POST增、PUT改、DELETE删
- 自描述消息：每个响应都包含足够的信息，告诉客户端怎么处理
- 超媒体驱动：响应里包含链接，引导客户端发现下一步操作
最后一点「超媒体驱动」很多人会忽略。我刚开始做API时也不重视，直到有一次对接第三方系统，对方问我「创建订单后下一步该调哪个接口？」我才意识到——好的API应该像网页一样，自带导航。
约束五：分层系统
客户端不知道它直接连的是最终服务器，还是中间代理。这种分层设计让架构更灵活——你可以加负载均衡、加缓存层、加安全网关，客户端完全无感知。
我在微服务架构中经常用这个约束。API网关做路由和鉴权，业务服务做核心逻辑，数据服务做持久化。每层各司其职，出了问题也容易定位。
约束六：按需代码（可选）
服务器可以给客户端返回可执行代码，比如JavaScript。这样客户端可以动态扩展功能。不过这个约束是可选的，实际项目中用得不多。我个人很少用，因为安全风险比较高。
| 约束 | 核心要求 | 我的实战建议 |
|---|---|---|
| 客户端-服务器分离 | 前后端解耦 | 接口文档先行，前后端并行开发 |
| 无状态 | 请求独立，不存会话 | 用JWT做认证，每次请求携带 |
| 可缓存 | 明确缓存策略 | 静态资源缓存7天，动态数据不缓存 |
| 统一接口 | 规范URL和方法 | 资源名用名词复数，动词用HTTP方法 |
| 分层系统 | 中间层透明 | 加API网关做统一入口 |
| 按需代码 | 可选，返回可执行代码 | 慎用，注意安全 |
1.3 RESTful API的优势
聊完约束，说说好处。为什么这么多公司选择RESTful API？我总结了几点：
- 简单直观：URL就是资源路径，HTTP方法就是操作。新手一看就懂。
- 语言无关：不管前端用React、Vue还是小程序，后端用Python、Java还是Go，都能对接。
- 可扩展性强：加新资源不影响旧接口。我经常在现有API上加版本号，比如/v1/users、/v2/users，平滑升级。
- 缓存友好：利用HTTP本身的缓存机制，性能提升明显。
- 生态成熟：各种工具、框架、文档生成器都支持RESTful。
1.4 适用场景
RESTful API不是万能的。我见过有人非要用RESTful做实时通信，结果搞得很别扭。下面说说它适合什么场景：
- Web应用后端：这是最常见的场景。用户管理、内容管理、电商系统，RESTful都能胜任。
- 移动端接口：手机App需要轻量级接口，RESTful的JSON格式正好合适。
- 微服务间通信：服务之间通过RESTful API交互，简单直接。
- 开放平台：对外提供API，让第三方开发者接入。比如微信支付API、GitHub API。
但如果你需要实时双向通信（比如聊天、游戏），或者对性能要求极高（比如高频交易），那RESTful可能不是最佳选择。这时候可以考虑WebSocket或gRPC。
好了，这一章就聊到这里。下一章我会带大家搭建开发环境，用Python写第一个RESTful API。到时候咱们边写边聊，把今天这些理论落到代码里。