一、官方文档对速率限制概述
官方文档地址:https://developer.twitter.com/en/docs/basics/rate-limits
根据官方文档说明可见:
此限制仅针对于standard API(标准接口)有效。对于Standard API,无论是post还是get对应的方法接口,均分为user auth和app auth两种频率限制。根据我对官方文档OAuth的部分说明的理解,使用“ OAuth 1”认证获取到的token对应的为“user auth”,使用“OAuth2”认证的token对应的为“app auth”。另外,使用user auth需要指明consumer_key、consumer_secret、access_token_key、access_token_secret四个参数,而app auth只需要指明consumer_key、consumer_secret两个参数。
以python使用的TwitterAPI包为例说明(pip install TwitterAPI):
由上图源码可见两种请求方法分别对应需要的参数,另外,使用OAuth2(app auth)需要在调用时指明auth_type参数为“OAUth2”。
二、不同的“接口”速率之间的关系
在Rate Limiting HTTP Headers and Response Codes部分,我们可见有三个参数可以查看我们当前请求过程所在的“一轮请求计数”总共的次数、剩余的次数、下次重新计数的时间戳。
以“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次。
我们使用debug模式请求某个端口,在返回结果的headers中可以对应找到这三个参数。我们用run 的方式使用同一个token请求其他端口,在此过程中继续debug之前的端口,可见,运行不同端口之间的请求不会互相干扰“x-rate-limit-remaining”的值。即,我们可以使用同一个token同时对不同的端口发出请求,程序设计中分别计算请求间隔应该设置的时间等待,防止出现请求频率过高导致的频率限制(对应status_code为420、429)。或者,我们可以在请求中通过剩余可用请求判断,若可用请求为1(或者0),进行时间等待至“当前时间时间戳==x-rate-limit-reset”。
部分代码示例:
# 若本次循环(15分钟的API请求循环),没有剩余可用的次数,则等待到下次循环 ***************
elif results.status_code == 200:
if int(results.headers['x-rate-limit-remaining']) == 0:
sleep_time = int(results.headers['x-rate-limit-reset']) - time.time()
time.sleep(sleep_time)
else:
pass
三、同一个用户授权多个APP对访问速率的影响
还是刚才的链接地址:GET and POST Request Limits,具体可参见下图。
根据红框中的内容可见:
此限制仅针对user auth,如果一个用户——用户X,授权了APPa及APPb,分别生成了TokenA、TokenB,如果使用TokenA请求了某个端口(例如GET followers/ids)n次,那么在本轮循环计数结束前使用TokenA与TokenB请求该端口的剩余次数之和为“15-n”。