【 ＜二＞ 丹方改良：Spring 时代的 JavaWeb】之 Restful的出现，背景和进化，矛盾与取舍
<前文回顾>
https://blog.csdn.net/foyodesigner/category_12907601.html?fromshare=blogcolumn&sharetype=blogcolumn&sharerId=12907601&sharerefer=PC&sharesource=FoyoDesigner&sharefrom=from_link<今日更新>
一、Restful 的诞生：从“业务驱动”到“技术革新”
Restful[1] 的出现，说白了就是“业务驱动”的结果。早期的 Web 开发，业务逻辑简单，数据交互少，西方国家的用户量也没那么大，高并发、数据保护和资源挖掘的需求并不强烈。Restful 的设计初衷是为了简化业务逻辑，而不是为了应对高并发或复杂的数据操作。
1. 业务驱动的设计理念
Restful 的设计理念是“资源导向”，它把一切数据都抽象成资源，用 HTTP 方法（GET、POST、PUT、DELETE）来操作这些资源。这种设计简单直接，适合早期的业务场景。
| HTTP Code |
| GET /users/1 # 获取用户1的信息 POST /users # 创建新用户 PUT /users/1 # 更新用户1的信息 DELETE /users/1 # 删除用户1 |
2. 无状态与 JSON 的崛起
Restful 的另一个核心思想是“无状态”，每次请求都包含所有必要的信息，服务器不需要保存客户端的状态。这种设计简化了服务器的逻辑，也方便了水平扩展。
JSON[2] 作为数据交换格式，比 XML 更轻量、更易读，逐渐成为 Restful API 的标准数据格式。
| JSON Code |
| { "id": 1, "name": "张三", "age": 25 } |
二、Restful 的进化：从“简单业务”到“复杂需求”
随着业务复杂度的增加，Restful 的设计理念开始暴露出一些问题。比如，软删除是否是删除？数据从已删除状态恢复为正常状态该如何处理？条件组合查询参数过多，无法使用 GET 等问题，都不在 Restful 的初期考虑范围内。
1. 软删除与状态恢复的矛盾
Restful 的设计中，DELETE 方法通常用于删除资源。但在实际业务中，很多场景需要“软删除”，即把资源标记为已删除，而不是真正从数据库中移除。这种需求与 Restful 的设计理念产生了矛盾。
| HTTP Code |
| DELETE /users/1 # 删除用户1 |
如果要用 Restful 实现软删除，通常得用 PATCH 或 PUT 方法来更新资源的状态。
| HTTP Code |
| PATCH /users/1 { "status": "deleted" } |
2. 复杂查询与 GET 的限制
Restful 的设计中，GET 方法用于获取资源，但 GET 请求的参数通常通过 URL 传递，长度有限。对于复杂的条件组合查询，GET 方法就显得力不从心了。
| HTTP Code |
| GET /users?name=张三&age=25&status=active # 查询名字为张三、年龄为25、状态为active的用户 |
对于更复杂的查询，通常得用 POST 方法，把查询条件放在请求体中。
| HTTP Code |
| POST /users/search { "conditions": { "name": "张三", "age": 25, "status": "active" } } |
三、Restful 的矛盾与取舍：从“理想”到“现实”
Restful 的设计理念虽然简洁，但在实际应用中，很多场景与 Restful 的设计产生了矛盾。这些矛盾主要体现在资源的操作方式、状态管理、复杂查询等方面。
1. 资源的操作方式
Restful 的设计中，资源的操作方式是通过 HTTP 方法来实现的。但在实际业务中，很多操作无法简单地映射到 GET、POST、PUT、DELETE 这四种方法上。
比如，用户登录操作，通常得用 POST 方法，而不是 GET 方法。
| HTTP Code |
| POST /login { "username": "admin", "password": "123456" } |
2. 状态管理
Restful 的设计中，服务器是无状态的，每次请求都包含所有必要的信息。但在实际业务中，很多场景需要服务器保存客户端的状态，比如用户的登录状态、购物车信息等。
| HTTP Code |
| POST /cart { "userId": 1, "productId": 101, "quantity": 2 } |
3. 复杂查询
Restful 的设计中，GET 方法用于获取资源，但 GET 请求的参数通常通过 URL 传递，长度有限。对于复杂的条件组合查询，GET 方法就显得力不从心了。
| HTTP Code |
| POST /users/search { "conditions": { "name": "张三", "age": 25, "status": "active" } } |
四、Restful 的“骚操作”
1. 自定义 HTTP 方法
有些框架支持自定义 HTTP 方法，比如 PATCH、OPTIONS 等，用来处理 Restful 无法直接支持的操作。
| HTTP Code |
| PATCH /users/1 { "status": "deleted" } |
2. GraphQL 的崛起
GraphQL[3] 是一种新的 API 查询语言，它允许客户端指定需要的数据结构，解决了 Restful 复杂查询的问题。
| GraphQL Code |
| query { user(id: 1) { name age status } } |
3. RPC 风格的 API
有些场景下，RPC（Remote Procedure Call）风格的 API 更适合复杂的业务逻辑。RPC 风格的 API 通常用 POST 方法，把操作名和参数放在请求体中。
| RPC Code |
| POST /rpc { "method": "login", "params": { "username": "admin", "password": "123456" } } |
五、Restful 的“历史”：从 2000 年到 2020 年
Restful 从 2000 年提出到现在，已经走过了 20 多个年头。虽然它的设计理念简洁，但在实际应用中，很多场景与 Restful 的设计产生了矛盾。
1. 2000 年：Restful 的提出
2000 年，Roy Fielding 在他的博士论文中提出了 Restful 的概念。Restful 的设计理念简洁，适合早期的 Web 开发。
2. 2010 年：Restful 的普及
2010 年，随着移动互联网的兴起，Restful API 逐渐成为主流。JSON 作为数据交换格式，比 XML 更轻量、更易读，逐渐成为 Restful API 的标准数据格式。
3. 2020 年：Restful 的挑战
2020 年，随着业务复杂度的增加，Restful 的设计理念开始暴露出一些问题。GraphQL、RPC 等新的 API 设计风格逐渐兴起，挑战了 Restful 的地位。
专有名词解释：
- Restful：一种基于 HTTP 协议的架构风格，强调资源的表述和状态转移。
- JSON：JavaScript Object Notation，一种轻量级的数据交换格式。
- GraphQL：一种 API 查询语言，允许客户端指定需要的数据结构。