因為安全問題，最終還是放棄了Rest！
作者：迷路的架構師
REST（Representational State Transfer）是一種軟件架構風格，用于設計網絡服務和API。它是由Roy Fielding在他的博士論文中提出，并成為HTTP協議的基石之一。
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看不出來、安全工具也掃不出來，萬事大吉！！
責任編輯：華軒
來源：
今日頭條
