REST 详解

飞滕人生TYF

于 2024-12-09 22:26:15 发布

阅读量2.3k

点赞数 24

分类专栏： java 文章标签： REST

本文链接：https://blog.youkuaiyun.com/T_Y_F_/article/details/144359371

版权

java 专栏收录该内容

210 篇文章

订阅专栏

REST（Representational State Transfer）详解

REST 是一种软件架构风格，常用于构建基于 HTTP 协议的分布式系统，尤其是 Web 服务。REST 的核心思想是通过统一的接口，使客户端与服务器之间能够松散耦合、高效通信。

一、REST 的定义

REST 是由 Roy Fielding 在 2000 年提出的一种架构风格，用于设计分布式网络应用。
它通过使用标准的 HTTP 方法 和资源建模，简化了客户端和服务器之间的交互。

全称：Representational State Transfer

Representation（表现形式）：资源可以通过多种形式表示（如 JSON、XML、HTML）。
State Transfer（状态转移）：通过操作资源的表现形式完成状态的改变。

二、REST 的六大架构约束

REST 依赖以下六大架构约束，这些约束是其核心理念：

客户端-服务器（Client-Server）
- 客户端与服务器职责分离：客户端负责用户界面，服务器负责资源存储和业务逻辑。
- 优点：提高可扩展性，客户端和服务器可以独立演进。
无状态（Stateless）
- 每个请求都是独立的，不依赖之前的请求。
- 服务器不保存客户端的会话状态，所有的状态信息都由客户端携带（如通过 URL、HTTP Headers 或 Cookies）。
- 优点：简化服务器设计，增强可扩展性。
可缓存性（Cacheable）
- 响应数据必须明确标识是否可缓存（通过 HTTP 缓存头）。
- 如果可缓存，客户端可复用响应数据，减少不必要的请求。
- 优点：提高性能，降低服务器负载。
统一接口（Uniform Interface）
- REST 使用统一的接口设计，简化客户端和服务器交互。
- 包括：
  - 资源的唯一标识符（URI）。
  - 使用标准的 HTTP 方法（如 GET、POST）。
  - 操作资源的表现形式（如 JSON、XML）。
分层系统（Layered System）
- 系统可以分为多个层（如代理服务器、负载均衡器、缓存）。
- 客户端不能直接感知到中间层的存在。
- 优点：增强系统的可扩展性和安全性。
按需代码（Code-on-Demand，非强制性）
- 客户端可以从服务器下载代码（如 JavaScript），以便扩展其功能。
- 优点：增强客户端的灵活性，但较少使用。

三、REST 的核心概念

1. 资源（Resource）

资源是 REST 的核心，一切皆资源。
资源的标识：
- 每个资源都有唯一的 URI（统一资源标识符）。
- 示例：
  - /users/1 表示用户 ID 为 1 的资源。
  - /products 表示产品列表资源。

2. 资源的表现形式（Representation）

资源可以有多种表现形式，如 JSON、XML、HTML。
表现形式通过 Content-Type 和 Accept HTTP 头来指定。

示例：

GET /users/1 HTTP/1.1
Accept: application/json

3. HTTP 方法

REST 使用标准的 HTTP 方法来操作资源：

方法	描述	示例
GET	获取资源（只读）	`GET /users/1`
POST	创建资源	`POST /users`
PUT	更新资源（替换整个资源）	`PUT /users/1`
PATCH	部分更新资源	`PATCH /users/1`
DELETE	删除资源	`DELETE /users/1`

4. 状态码（Status Code）

REST 使用 HTTP 状态码返回请求的结果：

状态码	描述	示例
200	请求成功	获取资源成功
201	资源已成功创建	创建用户成功
204	请求成功，无返回内容	删除资源成功
400	错误请求	请求数据无效
401	未授权	用户未认证
404	未找到资源	请求的资源不存在
500	服务器内部错误	服务端故障

5. 超媒体（HATEOAS）

全称：Hypermedia as the Engine of Application State。
资源的表现形式中包含可执行的下一步操作链接。

示例：

{
    "id": 1,
    "name": "John",
    "links": [
        {"rel": "self", "href": "/users/1"},
        {"rel": "orders", "href": "/users/1/orders"}
    ]
}

四、REST API 的设计原则

资源 URI 应描述资源本身：
- 使用名词而非动词。
- 示例：
  - 推荐：GET /users
  - 避免：GET /getUsers
使用 HTTP 方法表示操作：
- GET -> 获取，POST -> 创建，PUT -> 更新，DELETE -> 删除。
支持多种表现形式：
- 提供 JSON、XML 等常见格式的支持。
状态码表示操作结果：
- 使用标准 HTTP 状态码描述操作是否成功。
无状态性：
- 客户端每次请求都应携带完整的状态信息。
版本化 API：
- 使用版本号管理 API 的变更。
- 示例：/api/v1/users

五、REST 的优点与缺点

优点

简单性：
- 基于 HTTP，易于理解和实现。
松散耦合：
- 客户端和服务器分离，易于扩展。
可扩展性：
- 通过缓存和负载均衡提升性能。
标准化：
- 使用 HTTP 方法和状态码，统一接口设计。

缺点

缺乏实时性：
- 需要轮询获取数据，不适合实时通信。
无状态性限制：
- 无法直接保存客户端会话状态，需额外设计认证机制。
复杂性增加：
- 复杂的关系或批量操作需要额外设计。
HATEOAS 实现少：
- 超媒体原则很少被实际实现。

六、REST vs SOAP

特性	REST	SOAP
传输协议	主要使用 HTTP	支持多种协议（HTTP、SMTP 等）
消息格式	JSON、XML 等	主要为 XML
易用性	简单，使用标准 HTTP 方法	复杂，需处理 WSDL、SOAP 消息结构
性能	较高，支持缓存	较低，消息较冗长
实现难度	低	高
状态管理	无状态	支持有状态和无状态