REST API
REST 應用程式介面
REST API 是以訂單、使用者等資源為中心的 HTTP 介面。每次請求都要帶齊所需資訊，並遵守標準 HTTP 語意，也可支援快取和多層架構。
另一個例子
倉儲應用程式讀取 `/orders/784`，用有條件的 `PATCH` 修改配送地址，再依 `Link` 標頭前往追蹤資源。任何無狀態伺服器都能處理請求。若 `ETag` 已過期，伺服器會回傳 412，不會蓋掉較新的修改。
主要部分
- 01資源識別碼
- 02統一 HTTP 操作
- 03表述與連結
什麼時候用
當產品適合使用資源導向的 HTTP、快取、中介層，而且用戶端需要獨立演進時，可以採用 REST。
什麼時候不要用
API 不是只要透過 HTTP 傳 JSON 就叫 RESTful。有狀態工作階段、RPC 指令通道，或忽略 HTTP 語意，都是不同的設計。
程式裡的名稱
client-server + stateless + cache + uniform interface + layered system + hypermedia 上線前要檢查
檢查介面約定、任何情況都不能破壞的規則、授權與輸入限制。測試重試、重複執行只生效一次、逾時與部分失敗。驗證資料完整性、相容性、監控、復原與回復上一版。
預期成果：為這套系統設計或檢查 REST 應用程式介面 (REST API)，並讓資料保持正確、安全且容易維護。 使用者情境：倉儲應用程式讀取 `/orders/784`，用有條件的 `PATCH` 修改配送地址，再依 `Link` 標頭前往追蹤資源。任何無狀態伺服器都能處理請求。若 `ETag` 已過期，伺服器會回傳 412，不會蓋掉較新的修改。 技術概念或控制措施：REST 應用程式介面 (REST API)。 適用理由：當產品適合使用資源導向的 HTTP、快取、中介層，而且用戶端需要獨立演進時，可以採用 REST。 不應使用的情況：API 不是只要透過 HTTP 傳 JSON 就叫 RESTful。有狀態工作階段、RPC 指令通道，或忽略 HTTP 語意，都是不同的設計。 工程要求：定義輸入、輸出、介面約定，以及任何情況都不能破壞的規則。說明授權與輸入檢查範圍。定義失敗、逾時、重試和重複執行只生效一次的規則。也要定義資料搬移與相容限制。 營運要求：加入監控訊號與隱藏敏感資料的記錄。設定容量上限並寫好操作手冊。測試復原與回復上一版的流程。 驗收條件：介面約定與失敗路徑測試通過。重試或部分失敗時，資料與授權規則仍正確。效能上限、監控、復原與回復上一版的方法都已驗證。 證據與限制（證據邊界）：沒有一份官方標準能管到全部內容。不同團隊、平台或框架的用法可能不同。 待確認：程式執行環境、資料位置、流量形態、資料一致需求和安全邊界。也要確認相容期間、服務目標（SLO）與回復上一版的限制。
檢查這份需求
請 AI 程式助手檢查目前如何使用 REST 應用程式介面 (REST API)。 定義：REST API 是以訂單、使用者等資源為中心的 HTTP 介面。每次請求都要帶齊所需資訊，並遵守標準 HTTP 語意，也可支援快取和多層架構。 正式環境檢查：檢查介面約定、任何情況都不能破壞的規則、授權與輸入限制。測試重試、重複執行只生效一次、逾時與部分失敗。驗證資料完整性、相容性、監控、復原與回復上一版。 修改程式前，先列出看到的證據、缺口、嚴重程度，以及最小且安全的修正。