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示例
下面是一个简单的REST示例,以管理用户资源为例:
- 获取用户列表:发送GET请求来获取所有用户信息。
GET /users
- 获取特定用户:发送GET请求来获取特定用户的详细信息。使用用户ID作为路径参数。
GET /users/{user_id}
- 创建用户:发送POST请求来创建新用户。请求体中包含新用户的信息。
POST /users
Request Body:
{
"name": "John Doe",
"emAIl": "johndoe@example.com",
"age": 25
}
- 更新用户:发送PUT请求来更新特定用户的信息。使用用户ID作为路径参数,并在请求体中包含更新后的用户信息。
PUT /users/{user_id}
Request Body:
{
"name": "Jane Smith",
"email": "janesmith@example.com",
"age": 30
}
- 删除用户:发送DELETE请求来删除特定用户。使用用户ID作为路径参数。
DELETE /users/{user_id}
Rest优点
用了这么多年 Rest,总结几个优点(从上述示例也可以看出)。
- Rest 具备规范性,GET/POST/PUT/DELETE 分别代表 获取/创建/修改/删除 操作。
- Rest 表意明确,可读性强,代码清晰。
- GET/PUT/DELETE 都是幂等的,若操作失败,可以进行重试,确保资源的一致性。一些框架可以基于此特性做一些重试机制。
但是最近的一系列安全问题,最终我们放弃了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 就能看到请求参数,不安全!!!
解决方案
将所有请求都改成 POST ,请求参数放在 Body 中,前端做一层简单的签名和加密。F12看不出来、安全工具也扫不出来,万事大吉!!