速率限制 是 API 提供者用來管理在特定時段內對其服務提出要求數目的常見技術。 API 提供者會使用速率限制來確保其服務仍可供所有使用者使用及回應，以及防止濫用或過度使用服務。
當您在應用程式中使用雲端 API 時，您應該瞭解其速率限制。 下列技術可協助您處理應用程式中的速率限制：
- 瞭解速率限制。 請檢查您所使用的 API 文件以瞭解其調用限制。 速率限制可能取決於您使用的 API 提供者或服務方案。 例如，某些 API 可能會有不同的免費和付費方案費率限制。
- 使用速率限制資訊。 使用速率限制的 API 通常會在回應標頭中傳達目前的限制。 例如，標頭
RateLimit-Remaining會指出目前視窗中保留的要求數目。 如果您收到此標頭設定為 0 的回應，您知道您已達到速率限制，而且應該在傳送另一個要求之前等候下一個視窗。RateLimit-Reset標頭表示速率限制重設的時間。 標頭名稱與格式會因 API 而異：例如 GitHub 使用x-ratelimit-remaining和x-ratelimit-reset以 UTC 紀元秒計。 有些 API 只有在達到門檻後才會傳送標頭。 例如，當您的要求剩餘 10 個% 時。 - 優化 API 使用量。 有些服務會根據其複雜性，將不同的成本指派給不同的要求。 例如，某些 API 可能會針對傳回更多數據的要求收取更多費用。 若要降低應用程式的成本，請只擷取您所需的數據，以優化 API 使用量。 如果 API 支援批次要求，請使用批次要求。 其可協助您減少處理回應所需的資源數目，並維持在速率限制內。
- 實作本地速率限制器。 在應用程式本身內實作速率限制器，以限制在特定時段內對 API 提出的要求數目。 您可以使用令牌桶或漏桶演算法等技術來執行此作業，讓應用程式可在每個時段提出許多要求。 進一步的要求會被排入佇列或被捨棄。
- 避免超過速率限制。 當你超過速率限制時，API 會對你的請求進行節流，通常會使用 HTTP
429 Too Many Requests狀態碼。 節流對應用程式吞吐量的影響比速率限制還大。 利用速率限制回應標頭中的資訊，保持在速率範圍內，避免遭到節流。
藉由使用這些技術，您可以建置可復原速率限制的應用程式，即使 API 負載過重，仍可繼續運作。 然後測試它們是否確實會觸發速率限制，因為在開發過程中很少會達到速率上限。
如何測試你的速率限制處理
| Approach | 你發現的 | 你錯過的內容 |
|---|---|---|
| 等待正式環境 | 實際速率限制 | 在使用者觸發之前，一切皆如此 |
| 在測試中模擬 API，或讓你的程式代理寫出模擬 | 你的程式碼是否能讀取你模擬的標頭 | API 的真實標頭名稱、格式和重置行為，以及你 SDK 的重試政策。 你的應用程式也需要一個只供測試使用的開關來連到模擬端點。 |
| 一直呼叫真正的 API，直到觸及上限 | 實際行為 | 你無法隨時觸及限制，會用掉真正的配額，有些限制只會在一小時後重置 |
| 攔截你應用程式的真實流量並模擬限制條件 | 真實網址、你選擇的限制和時間範圍，以及 API 本身的標頭 | 你的程式碼獨立呈現。 那個就留給單元測試吧。 |
在你的應用程式上試試看
Dev Proxy 會計算你的應用程式對你所選擇之 API 發出的請求數，並在回應中加入速率限制標頭；當你的應用程式超出限制時，會以 429 回應，而應用程式則持續呼叫真實網址。 你可以選擇限制和時間範圍，所以你可以在一分鐘內達到限制，而不是一小時。
用於 GitHub，下載預設並使用該預設啟動 Dev Proxy：
devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"
對於 Microsoft Graph 呼叫 OneDrive 和 SharePoint（/drive、/shares、/sites），請使用 microsoft-graph-rate-limiting 預設集。 要安裝 Dev Proxy，請參見 設定 Dev Proxy。
