推特標(biāo)準(zhǔn)接口API的請求頻率限制說明（2）

Rate limiting

注：只針對標(biāo)準(zhǔn)API端口，高級API不在討論范圍內(nèi)。

每個用戶或每個應(yīng)用程序

標(biāo)準(zhǔn)API的速率限制主要基于每個用戶，或者更準(zhǔn)確地說，基于每個用戶的訪問令牌。如果一個方法允許每個端口接收15個請求，那么它允許每個訪問令牌訪問該窗口15個請求。（大白話就是限制15個請求就只能允許你訪問15次）

使用僅應(yīng)用程序身份驗證時，將全局確定整個應(yīng)用程序的速率限制。如果一個方法允許每個端口接收15個請求，那么它允許您代表應(yīng)用程序為每個窗口發(fā)出15個請求。此限制與每個用戶的限制完全分開考慮。

15分鐘間隔

速率限制分為15分鐘間隔。所有端口在請求時都需要身份驗證。

有兩種initial buckets可用于GET請求：每15分鐘15個請求，每15分鐘180個請求。

HTTP頭部和響應(yīng)代碼

使用HTTP頭可以了解在給定的速率限制下，應(yīng)用程序在剛剛使用的方法上的狀態(tài)。

Http Headers

上圖是HTTP Headers and Response Codes部分，可以看到有三個參數(shù)可以查看當(dāng)前請求過程所在的“一輪請求計數(shù)”總共的次數(shù)、剩余的次數(shù)、下次重新計數(shù)的時間戳。

注意，HTTP頭是上下文的。當(dāng)使用app-only auth的身份驗證時，它們指示應(yīng)用程序上下文的速率限制。使用user-based auth的身份驗證時，它們指示該用戶應(yīng)用程序上下文的速率限制。

當(dāng)應(yīng)用程序超過給定標(biāo)準(zhǔn)API終結(jié)點的速率限制時，API將返回一個HTTP 429“太多請求”響應(yīng)代碼，并在響應(yīng)正文中返回以下錯誤：

返回錯誤

為了更好地知道可用的速率限制，請考慮定期使用GET application/rate_limit_status方法（這兩個方法后面會介紹）。

「Janebook」的原創(chuàng)文章更好的解釋了這幾個參數(shù)的使用，在此處貼出部分內(nèi)容：

以“GET followers/ids”接口為例，文檔顯示15分鐘為一個計數(shù)循環(huán)，15分鐘內(nèi)單個用戶（不同用戶請求沒有測試）使用“user auth”最多請求15次該接口。計數(shù)從每一輪循環(huán)的第一次發(fā)出請求開始計算本輪循環(huán)的15分鐘，對應(yīng)x-rate-limint-reset參數(shù)，即為本輪首次發(fā)出請求時的時間戳+1560對應(yīng)的數(shù)字。x-rate-limit-limit對于此接口來說為15（不變的固定值），一輪循環(huán)中加入已經(jīng)請求了N次，則對應(yīng)的x-rate-limit-remaining為15-N次。*

GET and POST請求限制

從系統(tǒng)中讀取的速率限制（GET）是根據(jù)每個用戶和每個應(yīng)用程序定義的，而寫入系統(tǒng)（POST）的速率限制僅在用戶帳戶級別定義。換句話說，對于讀取速率限制，請考慮以下情況：

這部分看不懂也沒問題，大概意思是：

對于user auth來說，如果一個用戶X，授權(quán)了APPa及APPb，分別生成了TokenA、TokenB，如果使用TokenA請求了某個端口（例如GET friends/list）n次，那么在本輪循環(huán)計數(shù)結(jié)束前使用TokenA與TokenB請求該端口的剩余次數(shù)之和為“15-n”。

避免速率受限的技巧

緩存

如果您希望大量使用API，請將響應(yīng)存儲在您的應(yīng)用程序或網(wǎng)站中。例如，請勿嘗試在網(wǎng)站登錄頁面的每個頁面加載上調(diào)用Twitter API。而是不經(jīng)常調(diào)用API，并將響應(yīng)加載到本地緩存中。當(dāng)用戶訪問您的網(wǎng)站時，加載結(jié)果的緩存版本。

優(yōu)先考慮活動用戶

如果您的站點跟蹤許多Twitter用戶（例如，獲取其當(dāng)前狀態(tài)或有關(guān)Twitter使用情況的統(tǒng)計信息），請考慮僅請求最近登錄您站點的用戶的數(shù)據(jù)。

反正最好的突破頻率限制的方法還是充錢=。=