RESTful 设计风格

最新推荐文章于 2025-07-07 21:15:30 发布

kaf_u

最新推荐文章于 2025-07-07 21:15:30 发布

阅读量1.4k

点赞数 15

CC 4.0 BY-SA版权

分类专栏：后端学习笔记文章标签： restful 后端

本文链接：https://blog.csdn.net/m0_46515715/article/details/146964884

后端学习笔记专栏收录该内容

12 篇文章

订阅专栏

RESTful 设计风格

RESTful 是一种基于 REST（Representational State Transfer，表述性状态转移） 架构风格的软件设计模式，旨在通过简洁、统一、标准化的方式实现分布式系统间的交互。其核心思想是将资源抽象为可操作的实体，并通过 HTTP 协议的标准方法（如 GET、POST、PUT、DELETE）来实现客户端与服务器之间的通信。

一、REST 的起源与核心思想

起源

由 Roy Fielding 在 2000 年的博士论文中提出，目的是为 Web 应用设计一种可扩展、松散耦合、高效的架构风格。
其灵感来源于 Web 本身的成功：通过 URI 标识资源，通过 HTTP 方法操作资源，通过超媒体（如链接）驱动状态转移。

核心思想

资源为中心：将数据和功能抽象为资源（Resource），每个资源通过唯一的 URI 标识。
无状态通信：每个请求必须包含完成操作所需的所有信息，服务器不保存客户端状态。
统一接口：通过标准化的 HTTP 方法和语义定义操作，简化系统设计。

二、REST 的六个核心约束

RESTful 风格必须满足以下六个约束条件：

客户端-服务器分离（Client-Server）

客户端负责用户交互和状态管理，服务器负责数据存储和业务逻辑。
两者独立演化，通过接口解耦（例如前端与后端分离）。

无状态（Stateless）

每个请求必须包含处理所需的所有信息（如认证 Token、请求参数）。
服务器不保存客户端会话状态（例如不依赖 Session），所有状态由客户端维护。

可缓存（Cacheable）

服务器通过 HTTP 头（如 Cache-Control、ETag）明确标记响应是否可缓存。
客户端或中间节点（如 CDN）可缓存响应，减少服务器压力。

统一接口（Uniform Interface）

资源标识：通过 URI 唯一标识资源（如 /users/123）。
资源操作：通过 HTTP 方法（GET、POST、PUT、DELETE）操作资源。
自描述消息：请求和响应包含足够的信息（如 Content-Type 指定数据格式）。
超媒体驱动（HATEOAS）：响应中提供相关操作的链接（如分页导航、关联资源）。

分层系统（Layered System）

系统可分层设计（如负载均衡、网关、缓存层），客户端无需关心中间层。
提升可扩展性和安全性（例如通过网关统一鉴权）。

按需代码（Code-On-Demand，可选）

服务器可返回可执行代码（如 JavaScript），由客户端动态执行。
此约束在 RESTful API 中较少使用。

三、RESTful 风格的核心设计原则

资源与 URI 设计

资源抽象：所有数据或服务抽象为资源（如用户、订单）。
URI 规范：
- 使用名词（而非动词）表示资源，例如：
```
/users         # 用户集合
/users/123     # ID 为 123 的用户
/users/123/orders  # 用户 123 的订单
```
- 层级结构清晰，避免过度嵌套（如 /users/123/orders/456）。
- 使用连字符（-）分隔单词，而非下划线（如 /product-categories）。

HTTP 方法语义化

GET：获取资源（幂等操作，无副作用）。
POST：创建资源（非幂等，每次可能生成新资源）。
PUT：全量更新资源（幂等，需提供完整资源数据）。
DELETE：删除资源（幂等）。
PATCH：部分更新资源（仅传递需修改的字段）。

状态码（HTTP Status Codes）

通过标准 HTTP 状态码表示操作结果：
- 200 OK：请求成功。
- 201 Created：资源创建成功。
- 400 Bad Request：客户端请求错误。
- 401 Unauthorized：未认证。
- 404 Not Found：资源不存在。
- 500 Internal Server Error：服务器内部错误。

数据格式

使用通用格式（如 JSON、XML），在 HTTP 头中声明 Content-Type（如 application/json）。

示例（JSON 格式）：

{
  "id": 123,
  "name": "Alice",
  "email": "alice@example.com",
  "_links": {
    "self": { "href": "/users/123" },
    "orders": { "href": "/users/123/orders" }
  }
}

超媒体驱动（HATEOAS）

响应中包含相关操作的链接（Hypermedia as the Engine of Application State），客户端通过链接发现下一步操作。

示例（分页导航）：

{
  "data": [ ... ],
  "_links": {
    "next": { "href": "/users?page=2" },
    "prev": { "href": "/users?page=1" }
  }
}

四、RESTful 风格的优点

简单性

基于 HTTP 标准，开发工具天然支持（如浏览器、Postman）。

松耦合

客户端与服务器独立演化，只需保持接口兼容。

可扩展性

无状态设计便于水平扩展（如微服务架构）。

跨平台性

支持多种数据格式（JSON/XML），适用于 Web、移动端、IoT 等场景。

五、常见误区与反模式

URI 中包含动词

错误示例：/api/getUser?id=123
正确示例：GET /api/users/123

滥用 POST 方法

错误示例：用 POST 实现查询或更新操作。
正确示例：用 GET 查询，PUT/PATCH 更新。

忽略状态码语义

错误示例：所有响应均返回 200 OK，通过消息体表示错误。
正确示例：合理使用 4xx 和 5xx 状态码。

缺乏超媒体支持

错误示例：客户端硬编码 API 路径（如 /users/123/orders）。
正确示例：通过 HATEOAS 动态发现链接。

六、RESTful 与其他架构风格对比

特性	RESTful	RPC	SOAP
协议	HTTP	任意（如 HTTP、TCP）	HTTP、SMTP 等
数据格式	JSON、XML	自定义	XML
核心思想	资源操作	远程过程调用	严格的消息协议
灵活性	高	中	低（依赖 WSDL）
适用场景	前后端分离、开放平台	内部高性能调用	企业级复杂事务

七、实际设计示例

获取用户列表

GET /users?page=1&limit=10
Accept: application/json

响应：

{
  "data": [ ... ],
  "_links": { "next": "/users?page=2" }
}

创建用户

POST /users
Content-Type: application/json
{
  "name": "Bob",
  "email": "bob@example.com"
}

响应：

HTTP/1.1 201 Created
Location: /users/456

删除用户

DELETE /users/456

响应：

HTTP/1.1 204 No Content