
HTTP API vs WebSocket API:選擇哪個來實現實時通信?
它并不是一個具體的規范,而是一套自 2000 年代初以來成為構建 Web API 共同標準的新規則。遵循 REST 標準的 API 被稱為 RESTful API。一些實際的例子包括 Twilio、Stripe 和 Google Maps。
RESTful API 的基本概念
RESTful API 將資源組織成一組獨特的 URI(Uniform Resource Identifiers,統一資源標識符)。URI 用于區分服務器上的不同資源類型。以下是一些示例:
/products
,而不是 /getAllProducts
。客戶端通過 HTTP 向資源的端點發送請求來與資源交互。請求具有非常特定的格式,如下所示:
你可能聽說過 CRUD(Create、Read、Update、Delete),這就是它的含義。
請求正文
請求的正文中可以包含一個可選的 HTTP 請求正文,其中包含自定義數據負載,通常以 JSON 格式編碼。
服務器響應
服務器接收到請求后,會處理它并將結果格式化為響應。響應的第一行包含 HTTP 狀態碼,用于告知客戶端請求的結果:
表現良好的客戶端可以選擇重試帶有 500 級狀態碼的失敗請求。我們說“可以選擇重試”,是因為某些操作不是冪等的,重試時需要格外小心。當 API 是冪等的,多次發送相同的請求與發送一次請求的效果相同。通常,創建新資源的 POST 請求不是冪等的。
響應正文是可選的,可以包含數據負載,通常以 JSON 格式呈現。
無狀態
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