API 設計和 CRUD：

因此，重點主要在于定義如何將 CRUD 操作暴露給與電子商務 API 交互的用戶或系統。

CRUD 表示創建、讀取、更新、刪除。這些是任何數據驅動應用程序的基本操作。

例如，要添加一個新產品（創建），您需要向 /api/products 發送一個 POST 請求，在請求體中發送產品詳細信息。

要檢索產品（讀取），則需要從 /products 發送 GET 請求獲取數據。

要更新產品信息（更新），我們需要向 /products/:id 發送 PUT 或 PATCH 請求，其中 id 是我們需要更新的產品的 id。

刪除與更新類似；我們向 /products/:id 發送 DELETE 請求，其中 id 是我們需要刪除（Delete）的產品。

通信協議和數據傳輸機制

另一部分是決定要使用的通信協議，如 HTTP、Web Sockets 等，以及數據傳輸機制：JSON、XML 或協議緩沖區。

RESTful API 就是這種情況，但我們也有 GraphQL 或 gRPC 范例

API范式

API 有不同的范式，每個范式都有自己的一套協議和標準。

REST（表征狀態傳輸）

優點：客戶端向服務器發出的每個請求都必須包含理解和完成請求所需的全部信息。使用標準 HTTP 方法（GET、POST、PUT、DELETE）。便于不同客戶端（瀏覽器、移動應用程序）使用。

缺點：這可能導致數據抓取過度或抓取不足，因為可能需要更多端點來訪問特定數據。

特點是支持分頁、過濾（限制、偏移）和排序。使用 JSON 進行數據交換。

GraphQL

優點允許客戶端準確請求所需內容，避免過度抓取和抓取不足。基于模式的強類型查詢。

缺點：復雜的查詢會影響服務器性能。所有請求都以 POST 請求的形式發送。

特點通常以 HTTP 200 狀態代碼響應，即使出現錯誤，也會在響應正文中提供錯誤詳細信息。

gRPC（谷歌遠程過程調用）

優點基于 HTTP/2 構建，提供多路復用和服務器推送等高級功能。使用協議緩沖區，這是一種語言中立、平臺中立、可擴展的結構化數據序列化方式。有效利用帶寬和資源，尤其適合微服務。

缺點：與 JSON 相比，人類可讀性較差。需要 HTTP/2 支持。

特點是支持數據流和雙向通信，是服務器到服務器通信的理想選擇。

API設計中的關系

在電子商務環境中，可能存在用戶與訂單、訂單與產品等關系。

設計端點來反映這些關系非常重要。例如，在這種情況下，GET /users/{userId}/orders 應獲取特定用戶的訂單。

查詢、限制和 GET 請求的冪等性

常見的查詢還包括用于分頁的 limit 和 offset，或用于過濾特定日期范圍內產品的 startDate 和 endDate。這樣，用戶就可以檢索特定的數據集，而不會同時向系統或用戶提供過多的信息。

一個設計良好的 GET 請求是冪等的，這意味著多次調用它不會改變結果。

GET 請求絕不能更改數據。它們只用于檢索。

向后兼容性和版本控制：

在修改端點時，保持向后兼容性非常重要。這意味著要確保更改不會破壞現有客戶端。

版本控制：引入版本（如 /v2/產品）是處理重大變更的常見做法。

就 GraphQL 而言，在不刪除舊字段的情況下添加新字段（v2 字段）有助于在不破壞現有客戶端的情況下發展應用程序接口。

速率限制和 CORS

另一種最佳做法是設置速率限制。這用于控制用戶在一定時間內的請求數量。這對于保持 API 的可靠性和可用性至關重要。它還能防止 API 遭受 DDoS 攻擊。

常見做法是同時設置 CORS 設置 跨源資源共享（CORS）設置對網絡安全非常重要。它們可以控制哪些域可以訪問您的應用程序接口，防止不必要的跨站交互。

原文鏈接：API design 101 from basics to best practices