速率限制規定了客戶端在特定時間窗內可發送的請求數量，一旦超過上限，就會返回 429 錯誤。此限制旨在防止單一客戶端佔用所有共享資源，因此正確的回應是放慢速度，而非立即重複發送相同的請求。
大多數首次整合的客戶端都會立即重試，這將暫時的拒絕變成了持續性的問題。客戶端觸及限制後，立即重試，反而延長了測量時間窗，導致被節流的時間遠超最初的突發需求，開發者通常會因此認為 API 不可靠。我們刻意不包含您自己的限制配置：例如各層級的閾值、突發流量額度，以及限制更嚴格的端點，這些資訊應屬於版本化的文件，而非會過時的影片內容。
此範本透過八個場景追蹤一個請求：一個解釋為何存在限制，一個說明時間窗及其計算方式，一個介紹 429 回應的內容，兩個關於退避機制及為何延遲必須增加，一個關於抖動（jitter）和雷鳴般的羊群效應（thundering herd），一個關於如何讀取速率限制標頭，以及一個關於如何設計以避免觸及限制。
開發者教育必須與使用者已開啟的文件競爭。任何重複參考頁面的內容都會在二十秒內被關閉，因此此模組必須傳達文件難以有效溝通的內容：即失敗模式，而非單純的參數。
客戶端每 200 毫秒就對已超出限制的 API 進行重試，這就是問題的癥結所在，一個場景就能清楚呈現。退避機制隨後便作為顯而易見的解決方案出現，而非僅僅是建議。
一秒、兩秒、四秒、八秒。直接說明進程比定義指數退避更快，這也是開發者實際會實作的方式。
若無隨機化，每個被節流的客戶端將同時重試，導致恢復嘗試變成下一次服務中斷。這是大多數整合方案所忽略的部分，也是此模組存在的意義。
限制會變動，但報告限制的標頭不會。教導客戶端讀取所提供的資訊，勝過硬編碼一個下個季度就會失效的閾值。
上傳您的 API 文件、發送給合作夥伴的整合指南，或上次上線的支援工單——最大 200 MB，格式為 PDF、DOC、DOCX、PPTX 或 TXT。場景可供編輯，原始文件保持不變。
.PNG)
標頭命名在不同平台間有所差異，開發者即使看到通用範例，仍需自行查找您的標頭。在場景中直接顯示真實名稱，可省去這一步驟。
.PNG)
有些平台會進行節流，有些會暫停金鑰，有些則會通知人工介入。明確說明後果，能讓合作夥伴更認真看待這些指引。
.PNG)
狀態碼、標頭名稱和參數值容易聽錯，但閱讀則能確保準確性。從九種字幕樣式中選擇，在整個開發者系列中保持一致，並確保程式碼術語在小尺寸下仍清晰可辨。
速率限制管理短時間窗（通常是數秒或一分鐘）內的請求速度，可透過等待恢復。配額則管理計費週期內的總量，且無法透過等待恢復。混淆兩者會導致客戶端在需要請求增加配額時卻選擇退避。
如果提供了 retry-after 值，請讀取該值，至少等待該時間，然後以每次後續失敗都會增加的延遲進行重試。立即重試或以固定短間隔重試只會延長節流時間，而非清除它。
端點名稱可以，這會讓模組更有用。但金鑰和令牌則不行，即使是已過期的也不行，因為培訓影片會在製作對象之外流傳，且其生命週期遠長於憑證。
因為在大多數實作中，失敗的請求仍會計入時間窗。每次重試都會讓客戶端更進一步超出上限，因此每次試圖避免等待的嘗試，都會增加清除限制所需的等待時間。
將您已發布的 API 文件透過此工具運行，然後在下一次合作夥伴整合之前，精修各個場景。
