使用這些基本 REST API 最佳實踐構建出色的 API
在這次深入探討中，我們將深入了解API設計，從基礎知識開始，逐步進階到定義出色API的最佳實踐。
作為開發者，你可能對許多這些概念很熟悉，但我將提供詳細的解釋，以加深你的理解。
讓我們考慮一個類似Shopify這樣的電子商務平臺的API。如果你不熟悉Shopify，它是一個著名的電子商務平臺，允許企業建立在線商店。
在API設計中，我們關注定義API的輸入（比如新產品的產品詳情）和輸出（比如當某人查詢產品時返回的信息）。
這意味著我們關注的是接口而不是低級實現。
因此，焦點主要是定義CRUD操作如何向使用您的電子商務API的用戶或系統公開。
CRUD代表Create、Read、Update、Delete。這些是任何數據驅動應用程序的基本操作。
例如，要添加新產品（創建），您將通過POST請求發送到/api/products，其中產品詳情包含在請求體中。
要檢索產品（讀取），您需要使用GET請求從/products獲取數據。
要更新產品信息（更新），我們使用PUT或PATCH請求到/products/:id，其中id是需要更新的產品的id。
刪除類似于更新；我們通過DELETE請求到/products/:id，其中id是需要移除的產品。
另一部分是決定要使用的通信協議，比如HTTP、WebSockets等，以及數據傳輸機制：JSON、XML或Protocol Buffers。
這適用于RESTful API，但我們還有GraphQL或gRPC范例。
API有不同的范例，每個范例都有其自己的一套協議和標準。
優勢： 無狀態：客戶端到服務器的每個請求都必須包含理解和完成請求所需的所有信息。使用標準的HTTP方法（GET、POST、PUT、DELETE）。易于被不同客戶端（瀏覽器、移動應用）消費。
缺點： 這可能導致數據的過多或過少獲取-因為可能需要更多的端點來訪問特定的數據。
特性： 支持分頁、過濾（**limit**、**offset**）和排序。使用JSON進行數據交換。
優勢： 允許客戶端請求確切需要的內容，避免過多或過少獲取。基于強類型模式的查詢。
缺點： 復雜的查詢可能會影響服務器性能。所有請求都以POST請求發送。
特性： 通常以HTTP 200狀態碼回應，即使在錯誤的情況下也是如此，并在響應體中提供錯誤詳細信息。
優勢： 構建在HTTP/2之上，提供了高級功能，如多路復用和服務器推送。使用Protocol Buffers，一種語言中立、平臺中立、可擴展的序列化結構化數據的方式。在帶寬和資源方面效率高，特別適用于微服務。
缺點： 與JSON相比，可讀性較
差。需要支持HTTP/2。
特性： 支持數據流和雙向通信。適用于服務器間通信。
在電子商務環境中，您可能會有諸如用戶到訂單、訂單到產品等的關系。
設計端點以反映這些關系是重要的。例如，在這種情況下，**GET /users/{userId}/orders**應該為特定用戶獲取訂單。
常見的查詢還包括用于分頁的**limit**和**offset**，或者用于在某個日期范圍內過濾產品的**startDate**和**endDate**。這允許用戶檢索特定集合的數據，而不會一次性向系統或用戶提供太多信息。
設計良好的GET請求是冪等的，這意味著多次調用它不會改變結果。
GET請求永遠不應該改變數據。它們只用于檢索。
在修改端點時，保持向后兼容性非常重要。這意味著確保更改不會破壞現有客戶端。
版本控制： 引入版本（比如**/v2/products**）是處理重大更改的常見做法。
在GraphQL的情況下，添加新字段（v2字段）而不刪除舊字段有助于在不破壞現有客戶端的情況下發展API。
另一個最佳實踐是設置速率限制。這用于控制用戶在一定時間內可以發起的請求次數。這對于維護API的可靠性和可用性至關重要。它還防止API受到DDoS攻擊。
通常做法還包括設置CORS設置（跨域資源共享）。CORS設置對于Web安全至關重要。它們控制哪些域可以訪問您的API，防止不希望的跨站點交互。
本文章轉載微信公眾號@小技術君