1.RESTful接口設計規範是什麼？
RESTful 接口設計規範是一種設計和構建網絡服務的標準方式，它依賴於 HTTP 協議，注重簡潔和可擴展性。
2.為什麼要使用RESTful接口設計規範？
使用 RESTful 接口設計規範有助於創建高效、易於理解和擴展的網絡服務。它基於 HTTP 協議，利用標準動詞（如 GET、POST）進行資源操作，使接口設計簡潔一致，便於開發和維護。RESTful 接口天然支持緩存、認證和無狀態通信，具有良好的擴展性和跨平台兼容性，非常適合分佈式系統和微服務架構。此外，它與 HTTP 協議緊密結合，支持標準化的錯誤處理和響應格式，便於調試和集成。
3.RESTful設計原則
- 統一接口：使用標準化的資源 URL，操作通過 HTTP 方法（GET、POST、PUT、DELETE）實現。
- 無狀態：每個請求獨立，服務器不存儲客户端狀態。
- 可緩存：支持 HTTP 緩存，提高性能。
- 分層系統：支持多層架構（如代理、緩存）以提升擴展性和安全性。
- 客户端-服務器分離：客户端與服務器各自獨立開發，互不依賴。
- 按需編碼（可選）：服務器可通過腳本擴展客户端功能。
- 面向資源：以資源為核心，每個資源有唯一的 URL，通過 HTTP 方法進行操作。
- 一致的命名規範：使用簡潔、統一的命名，通常為複數名詞，並避免動詞。
- 數據格式：通過 Content-Type 和 Accept 頭部協商格式，常用 JSON 作為數據交換格式。
- 安全性：使用 OAuth 2.0 進行身份驗證，使用 HTTPS 加密確保通信安全。
請求方式(method)有
GET–查詢(從服務器獲取資源);
POST—新增(從服務器中新建一個資源);
PUT—更新(在服務器中更新資源)，
DELETE—刪除(從服務器刪除資源)，
PATCH—部分更新(從服務器端更新部分資源)
4.RESTful命名規範
- 資源名稱使用名詞：資源應該用名詞命名，而不是動詞。RESTful API 的操作由 HTTP 方法來決定，而不是通過 URL。
-
使用複數名詞。
/users，/products -
使用嵌套結構表示層次關係：如果資源存在層次關係，可以使用嵌套結構。
GET /users/{userId}/orders 獲取某個用户的訂單 POST /users/{userId}/orders 創建某個用户的訂單 -
避免動詞： URL 中不要使用動詞，操作應該通過 HTTP 方法表達。
錯誤：/getUsers，/createUser 正確：GET /users，POST /users - 使用連字符（-）而非下劃線（_）
- 使用小寫字母
-
查詢參數用於過濾：對資源的過濾、排序等操作，可以通過查詢參數來實現。
過濾：/users?age=25 表示查詢年齡為 25 的用户。 排序：/users?sort=age,asc 表示按年齡升序排序。 分頁：/users?page=2&limit=10 表示查詢第 2 頁，每頁 10 條記錄。 - 狀態碼反映操作結果
常見的狀態碼
-
2xx 成功類
- 200 OK：請求成功，通常用於 GET、PUT 和 DELETE 請求。
- 201 Created：資源創建成功，通常用於 POST 請求。
- 204 No Content：請求成功但無返回內容，通常用於 DELETE 請求。
-
3xx 重定向類
- 304 Not Modified：資源未改變，可以使用緩存版本。
-
4xx 客户端錯誤類
- 400 Bad Request：請求有誤，通常用於參數格式不正確或缺少必要參數。
- 401 Unauthorized：需要身份驗證的請求未通過驗證。
- 403 Forbidden：服務器拒絕執行請求，通常因權限不足。
- 404 Not Found：請求的資源不存在。
-
5xx 服務器錯誤類
- 500 Internal Server Error：服務器內部錯誤，通常是由於代碼問題。
- 503 Service Unavailable：服務器臨時過載或維護中，稍後重試。
轉載自開思通智網：https://w3.opensnn.com/os/article/10001419
