本系列是對推特開發者文檔進行的翻譯，以便幫助開發人員使用API接口，難免有些地方存在不足，還請諒解。
關於如何獲得一個推特開發者賬號請看此貼：
推特開發者賬號的申請
或
搜索微信公衆號 twitterDeveloper 獲得幫助
Rate limiting
注：只針對標準API端口，高級API不在討論範圍內。
每個用戶或每個應用程序
標準API的速率限制主要基於每個用戶，或者更準確地說，基於每個用戶的訪問令牌。如果一個方法允許每個端口接收15個請求，那麼它允許每個訪問令牌訪問該窗口15個請求。（大白話就是限制15個請求就只能允許你訪問15次）
使用僅應用程序身份驗證時，將全局確定整個應用程序的速率限制。如果一個方法允許每個端口接收15個請求，那麼它允許您代表應用程序爲每個窗口發出15個請求。此限制與每個用戶的限制完全分開考慮。
15分鐘間隔
速率限制分爲15分鐘間隔。 所有端口在請求時都需要身份驗證。
有兩種initial buckets可用於GET請求：每15分鐘15個請求，每15分鐘180個請求。
HTTP頭部和響應代碼
使用HTTP頭可以瞭解在給定的速率限制下，應用程序在剛剛使用的方法上的狀態。
上圖是HTTP Headers and Response Codes部分，可以看到有三個參數可以查看當前請求過程所在的“一輪請求計數”總共的次數、剩餘的次數、下次重新計數的時間戳。
注意，HTTP頭是上下文的。當使用app-only auth的身份驗證時，它們指示應用程序上下文的速率限制。使用user-based auth的身份驗證時，它們指示該用戶應用程序上下文的速率限制。
當應用程序超過給定標準API終結點的速率限制時，API將返回一個HTTP 429“太多請求”響應代碼，並在響應正文中返回以下錯誤：
爲了更好地知道可用的速率限制，請考慮定期使用GET application/rate_limit_status方法（這兩個方法後面會介紹）。
「Janebook」的原創文章更好的解釋了這幾個參數的使用，在此處貼出部分內容：
以“GET followers/ids”接口爲例，文檔顯示15分鐘爲一個計數循環，15分鐘內單個用戶（不同用戶請求沒有測試）使用“user auth”最多請求15次該接口。計數從每一輪循環的第一次發出請求開始計算本輪循環的15分鐘，對應x-rate-limint-reset參數，即爲本輪首次發出請求時的時間戳+15*60對應的數字。x-rate-limit-limit對於此接口來說爲15（不變的固定值），一輪循環中加入已經請求了N次，則對應的x-rate-limit-remaining爲15-N次。
原文鏈接https://blog.csdn.net/qq_27378621/article/details/90382131
GET and POST 請求限制
從系統中讀取的速率限制（GET）是根據每個用戶和每個應用程序定義的，而寫入系統（POST）的速率限制僅在用戶帳戶級別定義。換句話說，對於讀取速率限制，請考慮以下情況：
這部分看不懂也沒問題，大概意思是：
對於user auth來說，如果一個用戶X，授權了APPa及APPb，分別生成了TokenA、TokenB，如果使用TokenA請求了某個端口（例如GET friends/list）n次，那麼在本輪循環計數結束前使用TokenA與TokenB請求該端口的剩餘次數之和爲“15-n”。
避免速率受限的技巧
緩存
如果您希望大量使用API，請將響應存儲在您的應用程序或網站中。例如，請勿嘗試在網站登錄頁面的每個頁面加載上調用Twitter API。而是不經常調用API，並將響應加載到本地緩存中。當用戶訪問您的網站時，加載結果的緩存版本。
優先考慮活動用戶
如果您的站點跟蹤許多Twitter用戶（例如，獲取其當前狀態或有關Twitter使用情況的統計信息），請考慮僅請求最近登錄您站點的用戶的數據。