因为安全问题，最终还是放弃了Rest！

REST（Representational State Transfer）是一种软件架构风格，用于设计网络服务和API。它是由Roy Fielding在他的博士论文中提出，并成为HTTP协议的基石之一。

REST基于以下几个主要原则：

资源（Resources）：将系统中的每个实体（如用户、产品、订单等）都视为一个资源，每个资源可以通过唯一的标识符进行访问。
统一接口（Uniform Interface）：使用统一的接口来处理资源，包括使用HTTP动词（GET、POST、PUT、DELETE等）进行操作，并通过URI（资源标识符）来定位资源。
无状态（Stateless）：服务器不会存储客户端的状态信息，每个请求都应该包含足够的信息以完成请求处理。
按需响应（Response on Demand）：服务器按照客户端请求的内容返回相应的数据，可以是HTML、JSON、XML等格式。
可缓存性（Caching）：对于可缓存的响应，客户端可以缓存结果以提高性能和减少对服务器的请求。

下面是一个简单的REST示例，以管理用户资源为例：

GET /users

GET /users/{user_id}

POST /users

Request Body:
{
  "name": "John Doe",
  "email": "[email protected]",
  "age": 25
}

PUT /users/{user_id}

Request Body:
{
  "name": "Jane Smith",
  "email": "[email protected]",
  "age": 30
}

DELETE /users/{user_id}

用了这么多年 Rest，总结几个优点（从上述示例也可以看出）。

但是最近的一系列安全问题，最终我们放弃了Rest。

由于我们是 ToG 行业，没有什么比安全更大的问题，任何技术的先进性在安全性面前都不值得一提。以下是着重碰到的安全问题：

国产安全软件（深信服等）将 PUT/DELETE 直接定性为非法请求，所有的此类请求都需要修改成 POST。以前的方案是我们在前端统一将 PUT/DELETE 改成 POST，在 HEADER 中将原始请求类型作为参数带到请求中，后端网关层统一将 POST 转为原始请求转发到对应的服务（前端和后端基本都不用改）。
暴力遍历问题。如 GET /users/{user_id} ，不法分子可以使用下述请求暴力获取数据，存在安全隐患。最近碰到个银行系统，必须要整改！！

GET /users/1
GET /users/2
GET /users/3
GET /users/...
GET /users/n

数据越权问题。前端请求 token 与请求参数代表的用户不一致，如 token 代表是 A 用户，但实际请求的 GET /order/{order_id} 中 order_id 是 B/C/D/E/…/N 用户的，存在数据越权访问。必须整改！！！
请求明文问题。用 GET 请求在参数中都是明文传输，直接可以通过浏览器 F12 就能看到请求参数，不安全！！！