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 /users1. 获取特定用户 ：发送GET请求来获取特定用户的详细信息 。使用用户ID作为路径参数 。 复制GET /users/{ user_id}1. 创建用户 ：发送POST请求来创建新用户 。请求体中包含新用户的信息 。 复制POST /users Request Body: { "name": "John Doe", "email": "johndoe@example.com", "age": 25 }1.2.3.4.5.6.7.8. 更新用户 ：发送PUT请求来更新特定用户的信息。使用用户ID作为路径参数 ，源码下载并在请求体中包含更新后的用户信息 。 复制PUT /users/{ user_id} Request Body: { "name": "Jane Smith", "email": "janesmith@example.com", "age": 30 }1.2.3.4.5.6.7.8. 删除用户 ：发送DELETE请求来删除特定用户 。使用用户ID作为路径参数 。 复制DELETE /users/{ user_id}1. 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/n1.2.3.4.5. 数据越权问题 。免费模板前端请求 token 与请求参数代表的用户不一致 ，如 token 代表是 A 用户 ，但实际请求的 GET /order/{ order_id} 中 order_id 是 B/C/D/E/.../N 用户的 ，存在数据越权访问 。必须整改 ！！ ！请求明文问题 。用 GET 请求在参数中都是明文传输 ，直接可以通过浏览器 F12 就能看到请求参数 ，不安全 ！ ！ ！解决方案将所有请求都改成 POST ，请求参数放在 Body 中 ，前端做一层简单的签名和加密 。F12看不出来、安全工具也扫不出来，万事大吉 ！ ！
技术雷达站
