1 使用描述性和有意義的資源名稱
選擇準確表示所代表實體的資源名稱，不使用泛泛或模糊的名稱。
2 正確使用 HTTP 方法
針對不同的操作使用適當的 HTTP 方法（GET、POST、PUT、DELETE、PATCH 等）。
圖片
3 為 API 進行版本控制
通過版本控制來確保向后兼容性，同時能夠在不破壞現有客戶端的情況下進行未來的增強。
圖片
4 正確使用 HTTP 狀態碼
返回適當的 HTTP 狀態碼來指示 API 請求的成功或失敗。
圖片
5 選擇 JSON 字段命名約定（并堅持使用）
盡管 JSON 標準沒有強制規定字段命名約定，但根據最佳實踐，我們應該選擇一種字段命名約定，并堅持使用。
圖片
6 使用一致的錯誤消息
在大多數情況下，僅僅依靠HTTP狀態碼無法很好地解釋錯誤的原因。為了幫助API使用者，應該提供結構化的JSON錯誤消息。這樣可以更清楚地說明錯誤的具體原因。
響應應包含以下信息：
- 錯誤代碼：一個機器可讀的錯誤代碼，用于標識具體的錯誤情況。
- 錯誤消息：一個人類可讀的消息，提供詳細的錯誤說明。
- 錯誤上下文：與錯誤相關的附加信息，例如請求 ID、導致錯誤的請求參數或導致錯誤的請求中的字段。
- 錯誤鏈接：指向資源或文檔的 URL，提供關于錯誤以及如何解決錯誤的額外信息。
- 時間戳：錯誤發生的時間。
7 使用查詢參數進行過濾、排序和搜索
查詢參數支持在HTTP請求的URL中提供附加信息，以便控制服務器返回的響應。通過使用查詢參數，可以定制您所需的特定結果。
圖片
8 實現身份驗證和授權
通過實施適當的身份驗證和授權機制來保護 API。
- 對于身份驗證使用 API 密鑰、令牌或 OAuth 2.0。
- 對于授權應用基于角色的訪問控制（RBAC）。
9 不要維護狀態
REST API 不應該在服務器上維護狀態，這是客戶端的責任。
這一點非常重要，因為它使 API 可以進行緩存、可擴展，并且與客戶端解耦。
例如，電子商務 API 可能使用 cookie 來維護購物車的狀態。然而，這種方法違反了 RESTful API 的關鍵原則——它們需要是無狀態的。
10 文檔化 API
為 API 提供全面的文檔，包括端點細節、請求/響應示例和使用指南。
- 使用 Swagger/OpenAPI 文檔。
- 使用基于 Markdown 的文檔（例如使用 Swagger UI 或 ReDoc 等工具）。
