URL約定，方法，錯誤（「GET」，「POST」，「PUT」，「DELETE」）

URL約定，方法，錯誤（「GET」，「POST」，「PUT」，「DELETE」）

可靠且易於理解的API開始計算接口構建規則。我們遵循REST最佳實踐,以確保每個開發人員都知道會發生什麼：URL結構是合乎邏輯的,方法對應於操作,錯誤易於解釋。

這降低了登錄閾值，簡化了集成，並允許在沒有混亂的情況下擴展系統。

URL和HTTP方法約定

方法	目的	查詢示例
'GET'	獲取資源	'GET/users/42'
「POST」	創建新的資源	「POST/users」
'PUT'	完全更新資源	'PUT/users/42'
'PATCH'	部分資源更新（opz.）	`PATCH /users/42`
'DELETE'	刪除資源	'DELETE/users/42'

復數形式使用的存在性（「/users」，「/devices」，「/games」）
嵌套實體被描述為層次結構（'/users/42/sessions'）
所有查詢均通過HTTPS進行

錯誤處理標準

代碼	值	示例消息
'400'	錯誤查詢	'Missing required field： email '
'401'	未經授權	'Invalid token or expired session'
'403'	「訪問資源」	禁止訪問
'404'	找不到	'ID 42 User not found'
'409'	沖突（例如重復）	「使用中的電子郵件」
'422'	驗證錯誤	'Field'age'必須成為數字'
'500'	內部服務器錯誤	'無法解決的異常，聯系支持'

錯誤響應結構：

```json
{
“ error “ : {
“ code “ : 400,
“ message “ : “ Missing required field: email “ ,
“ details “ : {...}
}
}
```

對開發人員的好處

快速理解API邏輯而無需多余的文檔
所有模塊和實體的統一方法
通過標準代碼和格式輕松調試和編寫
與OpenAPI/Swagger、Postman、SDK自動生成兼容
簡化支持、測試和CI/CD

在哪裏，特別重要

開放或合作夥伴API平臺
具有多個開發團隊的項目
微服務體系結構或API第一方法
具有大量實體和交互的系統

統一約定使API可靠、易於理解和方便。我們堅持最好的REST做法,以確保每次集成都能快速進行,沒有誤解,並具有最大的可預測性。