它并不是一個具體的規范，而是一套自 2000 年代初以來成為構建 Web API 共同標準的新規則。遵循 REST 標準的 API 被稱為 RESTful API。一些實際的例子包括 Twilio、Stripe 和 Google Maps。

REST API 基礎

RESTful API 的基本概念

RESTful API 將資源組織成一組獨特的 URI（Uniform Resource Identifiers，統一資源標識符）。URI 用于區分服務器上的不同資源類型。以下是一些示例：

• 資源應該按名詞而非動詞分組。例如，獲取所有產品的 API 應該是 /products，而不是 /getAllProducts。

• 客戶端通過 HTTP 向資源的端點發送請求來與資源交互。請求具有非常特定的格式，如下所示：

  • URI：我們想要訪問的資源的 URI。
  • HTTP 動詞：告訴服務器我們想要對資源執行什么操作。例如：
  • POST：創建新資源。
  • GET：讀取現有資源的數據。
  • PUT：更新現有資源。
  • DELETE：刪除現有資源。

你可能聽說過 CRUD（Create、Read、Update、Delete），這就是它的含義。

請求正文

請求的正文中可以包含一個可選的 HTTP 請求正文，其中包含自定義數據負載，通常以 JSON 格式編碼。

服務器響應

服務器接收到請求后，會處理它并將結果格式化為響應。響應的第一行包含 HTTP 狀態碼，用于告知客戶端請求的結果：

• 200 級代碼：請求成功。
• 400 級代碼：請求有誤，例如請求包含錯誤的語法。
• 500 級代碼：服務器出錯，例如服務不可用。

表現良好的客戶端可以選擇重試帶有 500 級狀態碼的失敗請求。我們說“可以選擇重試”，是因為某些操作不是冪等的，重試時需要格外小心。當 API 是冪等的，多次發送相同的請求與發送一次請求的效果相同。通常，創建新資源的 POST 請求不是冪等的。

響應正文是可選的，可以包含數據負載，通常以 JSON 格式呈現。

REST 的關鍵特性

無狀態

REST 實現應該是無狀態的。這意味著雙方不需要存儲彼此的任何信息，每個請求和響應（周期）都與其他所有請求和響應獨立。這使得 Web 應用程序易于擴展且表現良好。

分頁

如果 API 端點返回大量數據，應使用分頁。常見的分頁方案使用“limit”和“offset”作為參數。例如：

GET /products?limit=10&offset=20

如果未指定這些參數，服務器應假設合理的默認值。

版本控制

API 的版本控制非常重要。版本控制允許實現提供向后兼容性，以便在從一個版本引入破壞性更改到另一個版本時，消費者有足夠的時間遷移到下一個版本。有許多方法可以對 API 進行版本控制，最直接的方法是在 URI 上為資源前綴添加版本號。例如：

GET /v1/products

總結

RESTful API 在合理應用時簡單且有效。它可能不是所有公司的最佳選擇，但它簡單且足夠好，這就是它被廣泛使用的原因。還有其他流行的 API 選項，如 GraphQL 和 gRPC，我們將在單獨的文章中討論它們并進行比較。

原文引自YouTube視頻：https://www.youtube.com/watch?v=-mN3VyJuCjM

#你可能也喜歡這些API文章!

HTTP API vs WebSocket API：選擇哪個來實現實時通信？

深入了解 Gateway API 的推理擴展

GraphQL API滲透測試指南