為什麼採用基於複雜性的速率限制？
傳統 REST API 使用基於請求的速率限制，其中每個請求消耗相同的額度，無論你是獲取一個欄位還是數百個欄位，無論是讀取還是修改資料 - 儘管伺服器負載差異很大。
GraphQL 的基於查詢複雜性的方法透過根據實際請求的資料和執行的操作計算成本來解決此問題。這讓你更靈活地請求所需內容，同時提供可預測的伺服器負載。
速率限制
Zonos 使用基於點數的系統，其中每個查詢根據其複雜性扣除點數。你有一個可用點數池，該池：
- 以 3,000 點/秒速率補充（30,000 點/10 秒）
- 最大容量為 300,000 點
這允許你偶爾進行複雜查詢的突發，同時保持可持續的請求速度。
如何計算查詢成本
每個 GraphQL 請求的成本在執行前計算：
基礎成本
- 查詢： 5 點
- 變異： 10 點
- 對象： 返回的每個對象 1 點
- 標量欄位： 0 點（免費）
字符串、整數、ID 和布林值等標量欄位不增加成本。你只需為基本操作和返回的對象付費。
範例：簡單查詢
query { landedCost(id: "123") { id createdBy shipToCountry }}成本分解： 5（基礎查詢）+ 1（Landed Cost 對象）= 6 點
標量欄位（id、name、currency）是免費的。
範例：具有多個對象的查詢
{ orders(first: 10, filter: { status: COMPLETED }) { edges { cursor node { id } } }}成本分解： 5（基礎查詢）+ 10（10 個訂單 × 每個 1 點）= 15 點
範例：變異
mutation { landedCostCalculate(input: { ... }) { id }}成本分解： 10（基礎變異）+ 約 50（返回的對象）= 60 點
典型的 Landed Cost 計算花費約 60 點的複雜性。
檢視查詢複雜性
每個 API 回應都包含一個 zonos-query-complexity 標頭，顯示你的查詢成本：
zonos-query-complexity: 58此標頭告訴你查詢消耗的確切點數。使用它來監控你的 API 使用情況並優化昂貴的查詢。
處理速率限制
如果超過速率限制，你將收到錯誤訊息。要有效處理速率限制：
監控你的複雜性
檢查回應中的 zonos-query-complexity 標頭以瞭解你的查詢成本並識別昂貴的模式。
實施重試邏輯
如果觸發速率限制，實施指數退避和重試邏輯。由於該值區每秒以 3,000 點速率補充，請根據查詢複雜性計算適當的等待時間。
高效批次
GraphQL 允許你在單個請求中請求多個查詢：
{ landedCost(id: "landed_cost_123") { id createdAt } order(orderId: "order_123") { id status createdAt }}最佳實踐
只請求你需要的內容
查詢複雜性與你請求的資料成正比。建構你的查詢以僅獲取你實際使用的欄位和對象。
query { order(orderId: "order_123") { id status createdAt updatedAt items { id name quantity amount } shipments { id } }}對大型資料集進行分頁
當請求多個對象時，請使用合理的頁面大小：
{ orders(first: 100, filter: { status: COMPLETED }) { edges { cursor node { id } } }}每次請求 10-50 項，並根據需要透過結果進行分頁，而不是在單個查詢中請求數百個對象。
避免不必要的嵌套
每個嵌套對象都會增加你的複雜性。只在實際需要時才請求嵌套資料。
GraphQL API 速率限制
瞭解 Zonos 如何根據複雜性計算查詢成本。
Zonos 根據查詢複雜性而非請求數量對 GraphQL API 請求進行速率限制。這確保了公平使用，同時允許你請求所需的確切資料。