RESTful API概念起源及与Roy Fielding提出的REST的关联疑问

一、REST概念的起源 #

REST（Representational State Transfer）最早由Roy Fielding在2000年的博士论文《Architectural Styles and the Design of Network-based Software Architectures》中提出，它本质是一套分布式超媒体系统的架构设计约束集合，核心约束包括：

• 无状态：服务器不保存客户端的会话状态，每个请求都包含完整的身份验证和上下文信息
• 客户端-服务器分离：客户端负责UI展示，服务器负责数据存储与业务逻辑，两者解耦
• 统一接口：所有资源通过统一的接口进行交互，简化系统复杂度
• 可缓存：响应必须明确标记是否可缓存，提升性能
• 分层系统：通过分层架构（如网关、负载均衡）隐藏底层细节，提升系统扩展性
• 按需代码（可选）：允许服务器向客户端发送可执行代码扩展功能

此时的REST是一套严谨的架构设计原则，并非专门针对HTTP API而生。

二、RESTful API的演化与偏差 #

随着Web API的普及，行业逐渐把REST和HTTP协议绑定，慢慢演化出了如今被广泛使用的"RESTful API"概念：它不再严格遵循Fielding提出的所有REST约束，而是变成了一套基于HTTP的API设计最佳实践，核心特征包括：

• 用URI标识资源（比如/users/123代表ID为123的用户）
• 用HTTP方法对应资源操作：GET获取、POST创建、PUT更新、DELETE删除
• 用JSON/XML等格式返回资源表述
• 遵循HTTP状态码传递操作结果（200成功、404资源不存在、500服务器错误等）

这一演化过程中，Fielding强调的**超媒体作为应用状态引擎（HATEOAS）**几乎被行业普遍忽略——HATEOAS要求响应中包含可跳转的链接，让客户端无需硬编码URI即可探索系统功能，但实际开发中很少有API实现这一点。正因如此，当下的RESTful API和原始REST概念关联甚微，甚至存在偏差。

三、如何理解当下的"RESTful" #

要理清这个概念，需要区分两个层面：

1. 学术层面的REST：严格遵守Fielding论文中的所有约束，是一种完整的分布式架构风格，适用于需要高度可扩展、松耦合的超媒体系统（比如早期的Web本身）。
2. 工业界的RESTful API：是行业实践演化出的约定俗成术语，它借用了REST的部分核心思想（无状态、资源导向、HTTP方法语义），但放弃了过于严苛的约束（尤其是HATEOAS），目的是快速构建简洁、易交互、标准化的Web API。它更像是一种"实用派"的API设计范式，而非严格的REST架构实现。

简单来说，现在大家口中的"RESTful API"，本质是一套基于HTTP的标准化API设计套路，和Roy Fielding最初提出的REST架构风格已经不是同一个概念了。

内容的提问来源于stack exchange，提问作者Jason Yu