1. 引言
在日常开发中，我们经常听到“REST”和“HTTP”这两个术语被混用。但实际上，它们代表的是不同的概念。本文将深入探讨 REST 和 HTTP 各自的定义，以及它们之间的区别和联系。
2. 什么是 REST？
REST 的全称是 Representational State Transfer，最早由 Roy Fielding 在其博士论文中提出。它是一种面向分布式超媒体系统的架构风格，而不是标准或规范。
REST 的核心思想是构建一种松耦合、可扩展、适合互联网规模的系统架构。它具备以下几个关键特征：
2.1. 资源与表现形式
REST 的基本单元是“资源（Resource）”。资源可以是网页、图片、视频，也可以是抽象概念，比如用户列表或天气预报。每个资源必须具备唯一标识（通常通过 URI 表示）。
此外，资源可以有多种表现形式（Representation）。例如：
- 一个天气接口可以返回 HTML 页面或 JSON 数据
- 一个用户接口可以返回 XML 或 JSON 格式的数据
服务器负责管理资源的状态，而客户端可以选择使用哪种表现形式进行交互。
2.2. 统一接口（Uniform Interface）
统一接口是 REST 的标志性特征之一。它要求客户端通过标准操作来访问所有资源。这些操作包括：
GET：获取资源POST：创建资源PUT：更新资源DELETE：删除资源
统一接口的好处在于：
✅ 客户端和服务端解耦
✅ 接口变更对客户端影响小
✅ 更容易构建通用客户端工具
但也有一定限制：
❌ 某些场景下操作不够灵活
❌ 可能导致服务器性能略差于专用协议
2.3. 无状态（Stateless）
REST 要求所有操作必须是无状态的。这意味着：
- 每个请求都必须包含服务器处理所需的所有信息
- 服务器不保存客户端的上下文状态
这种设计带来的优势包括：
✅ 请求可独立处理，便于监控和调试
✅ 系统更可靠，故障恢复更容易
✅ 更容易横向扩展
但也有代价：
❌ 请求体积变大，重复数据增多
3. 什么是 HTTP？
HTTP（HyperText Transfer Protocol）是一种标准协议，由 IETF 制定和维护。它是互联网上大多数通信的基础，例如：
- 浏览器加载网页
- 移动端访问接口
- 流媒体播放视频
虽然 HTTP 和 REST 有很多相似之处，但它们本质上是不同的概念。
HTTP 的特点包括：
- 明确定义的请求方法（如 GET、POST、PUT、DELETE）
- 使用 URI 定位资源
- 支持多种数据格式（JSON、XML、HTML 等）
- 可扩展性强，支持中间代理、缓存等机制
3.1. URI 与媒体类型
在 HTTP 中，资源通常通过 URI（统一资源标识符）来访问。例如：
https://api.example.com/users/123
HTTP 支持客户端选择资源的表现形式，通常通过 Accept 请求头和 Content-Type 响应头来协商：
GET /weather HTTP/1.1
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{
"city": "Beijing",
"temperature": "25°C"
}
3.2. HTTP 方法
HTTP 提供了一组标准的方法，这些方法与 REST 中的统一接口理念高度契合：
| 方法 | 含义 | 对应操作 |
|---|---|---|
| GET | 获取资源 | Read |
| POST | 创建资源 | Create |
| PUT | 替换资源 | Update |
| DELETE | 删除资源 | Delete |
这些方法是预定义的，不能由服务端自定义，这与 SOAP 等协议形成鲜明对比。
3.3. HTTP 并不总是 RESTful
尽管 HTTP 本身具备很多 REST 特征，但它并不总是严格遵循 REST 原则。常见“踩坑点”包括：
⚠️ 使用 Cookie 和 Session 保存状态
这违反了 REST 的无状态原则。虽然方便，但不利于系统的可扩展性和缓存机制。
⚠️ URL 中嵌入操作逻辑
如下例所示：
https://www.foo.com/api/v1/customers?id=17&action=clone
虽然使用了 GET 方法，但通过 action=clone 来传递操作意图，这破坏了统一接口原则。因为“clone”这个操作不是所有资源都支持的，也不符合标准 HTTP 方法的语义。
4. 总结
REST 和 HTTP 是两个不同维度的概念：
| 对比项 | REST | HTTP |
|---|---|---|
| 类型 | 架构风格 | 通信协议 |
| 是否标准 | ❌ 不是 | ✅ 是 |
| 是否强制无状态 | ✅ 是 | ❌ 否（可使用 Session） |
| 是否统一接口 | ✅ 是 | ✅ 部分符合 |
| 是否适合 API | ✅ 非常适合 | ✅ 也适合 |
虽然 HTTP 并不完全等同于 REST，但由于其良好的设计和广泛支持，成为了构建 RESTful 系统的理想选择。理解它们的区别有助于我们在设计 API 时做出更合理的技术选型。