当前位置：首页 > news >正文

什么是 RESTful API？RESTful API 的设计原则有哪些？（URL 语义化、HTTP 方法对应操作、无状态等）

news 2025/10/27 14:22:04

什么是 RESTful API？

RESTful API 是一种基于 REST（Representational State Transfer，表述性状态转移）架构风格 设计的接口规范，用于在客户端和服务器之间通过 HTTP 协议进行数据交互。它强调以资源为中心，通过统一的接口和 HTTP 标准方法实现无状态的通信，具有简洁、可扩展、易理解的特点，是目前互联网中最流行的 API 设计风格之一。

RESTful API 的核心设计原则

1. 资源为中心，URL 语义化

资源标识：URL（Uniform Resource Locator）应直接指向资源（如用户、订单、商品等），而非操作（如“获取用户”“删除订单”）。资源通常用名词（复数形式更常见）表示，避免动词。
- 反例：/getUser?id=1（URL 包含操作动词）
- 正例：/users/1（直接标识“ID 为 1 的用户”这一资源）
层级结构：通过 URL 路径体现资源间的层级关系，使用斜杠（/）分隔。
- 示例：/users/1/orders（表示“ID 为 1 的用户的所有订单”）

2. HTTP 方法对应资源操作（CRUD 映射）

利用 HTTP 标准方法（动词）表示对资源的操作，实现“操作与方法绑定”，避免在 URL 中重复定义操作。常见映射关系：

HTTP 方法	含义	对应操作（CRUD）	示例
`GET`	获取资源	读取（Read）	`GET /users`（获取所有用户）
`POST`	提交新资源	创建（Create）	`POST /users`（新增用户，数据在请求体）
`PUT`	全量更新资源	更新（Update）	`PUT /users/1`（全量更新 ID=1 的用户）
`PATCH`	部分更新资源	部分更新（Partial Update）	`PATCH /users/1`（仅更新用户邮箱）
`DELETE`	删除资源	删除（Delete）	`DELETE /users/1`（删除 ID=1 的用户）

3. 无状态（Stateless）

服务器不存储客户端的状态信息，每次请求必须包含所有必要的信息（如身份认证、资源标识等），服务器仅根据当前请求处理并返回结果。
优点：降低服务器复杂度，提高可扩展性（便于水平扩展服务器节点）。
示例：客户端每次请求需携带 Token 进行身份验证，服务器不保存“用户是否已登录”的状态。

4. 资源的表述性（Representational）

服务器返回的是资源的“表述”（如 JSON、XML 等格式），而非资源本身。客户端通过表述操作资源，服务器根据表述更新资源状态。
示例：请求 GET /users/1 时，服务器返回 JSON 格式的用户信息（表述），而非数据库中的原始数据。

5. 统一接口（Uniform Interface）

通过标准化的接口简化交互，包括：

资源标识：每个资源有唯一的 URL。
操作通过 HTTP 方法定义：如 GET/POST 等（见原则 2）。
自描述消息：请求/响应中包含足够的元数据（如 Content-Type 表示数据格式，Status Code 表示处理结果）。
超媒体作为应用状态的引擎（HATEOAS）：响应中包含链接（Hyperlinks），引导客户端发现下一步可执行的操作（可选，严格 REST 推荐）。
- 示例：获取用户详情的响应中包含其订单的链接：{"id":1, "name":"Alice", "orders_url":"/users/1/orders"}