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

REST API 基礎

RESTful API 的基本概念

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

你可能聽說過 CRUD(Create、Read、Update、Delete),這就是它的含義。

請求正文

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

服務器響應

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

表現良好的客戶端可以選擇重試帶有 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

上一篇:

ASP.NET Core Web API 快速集成 Entity Framework Core:從安裝到數據預熱全流程

下一篇:

一步步教你進行 Python REST API 身份驗證
#你可能也喜歡這些API文章!

我們有何不同?

API服務商零注冊

多API并行試用

數據驅動選型,提升決策效率

查看全部API→
??

熱門場景實測,選對API

#AI文本生成大模型API

對比大模型API的內容創意新穎性、情感共鳴力、商業轉化潛力

25個渠道
一鍵對比試用API 限時免費

#AI深度推理大模型API

對比大模型API的邏輯推理準確性、分析深度、可視化建議合理性

10個渠道
一鍵對比試用API 限時免費