【问题标题】:Twitter API - POST favorites/create Specific Rate LimitTwitter API - 发布收藏夹/创建特定速率限制
【发布时间】:2018-10-09 10:35:33
【问题描述】:

我的脚本因 message undefined 错误而崩溃时遇到问题,此处已回答:TypeError: Cannot read property 'message' of undefined - Twitter API

事实证明,当达到速率限制时,错误消息的传递方式不同,因此 console.log('Try Favorite - ', err[0].message); 将返回错误,除非更改为 console.log('Try Favorite - ', err.message);

它现在输出为[[Apr 28 22:26:01.024]] [LOG] Try Favorite - HTTP Error: 429 Too Many Requests,这表明存在速率限制,但是,我没有找到明确的速率限制。

所有关于 POST 的文档都限制状态 1000,但是,在过去 8 小时的过程中,我计算了总共 22 个,所以它受到速率限制很奇怪。

有没有人有更清晰的文档?我发现的所有链接似乎都已失效。

我还可以补充一点,只有收藏夹受到影响,所有其他请求都正常工作。

编辑:添加最近的输出。 Undefined 将是 You already ____ed this tweet,但是,由于临时更改以防止应用崩溃,消息未定义。

[[Apr 28 23:57:00.560]] [LOG]   Try Favorite -  HTTP Error: 429 Too Many Requests
[[Apr 28 23:57:00.562]] [LOG]   Try Favorite -  HTTP Error: 429 Too Many Requests
[[Apr 28 23:57:00.563]] [LOG]   Try Favorite -  HTTP Error: 429 Too Many Requests
[[Apr 28 23:57:00.564]] [LOG]   Try Favorite -  HTTP Error: 429 Too Many Requests
[[Apr 28 23:57:00.575]] [LOG]   Try Favorite -  HTTP Error: 429 Too Many Requests
[[Apr 28 23:57:00.578]] [LOG]   Try Retweet -  undefined
[[Apr 28 23:57:00.583]] [LOG]   Try Favorite -  HTTP Error: 429 Too Many Requests
[[Apr 28 23:57:00.584]] [LOG]   Try Retweet -  undefined
[[Apr 28 23:57:00.589]] [LOG]   Try Favorite -  HTTP Error: 429 Too Many Requests
[[Apr 28 23:57:00.592]] [LOG]   Try Retweet -  undefined
[[Apr 28 23:57:00.593]] [LOG]   Try Retweet -  undefined
[[Apr 28 23:57:00.599]] [LOG]   Try Retweet -  undefined
[[Apr 28 23:57:00.604]] [LOG]   Try Retweet -  undefined
[[Apr 28 23:57:00.609]] [LOG]   Try Retweet -  undefined
[[Apr 28 23:57:00.619]] [LOG]   Retweeted: https://twitter.com/username/status/90374******24768
[[Apr 28 23:57:00.634]] [LOG]   Try Retweet -  undefined
[[Apr 28 23:57:00.671]] [LOG]   Try Retweet -  undefined
[[Apr 28 23:57:00.754]] [LOG]   Try Favorite -  HTTP Error: 429 Too Many Requests
[[Apr 28 23:57:00.800]] [LOG]   Favorited:  https://twitter.com/username/status/99037*******48615

编辑:被告知我明显超出了速率限制,但是这个问题仅在今天才出现,同时工作了 5 天。同样,转发仍然返回You have already retweeted this tweet,而收藏返回状态 429。

编辑:尝试对另一个只有状态/转发请求的测试用户进行测试,结果很好。尝试使用不同的测试用户(以避免最后一次测试使用)收藏夹/创建它并运行第一个间隔,然后在第二个请求后立即将速率限制为每 2 分钟 5 个请求,这意味着我被限制为 7 个收藏夹/创建每 4 分钟请求一次。

这让我相信收藏夹有一个特定的限制,但是,当这个确切的时间间隔在 5 天前有效时,仍然不清楚。

【问题讨论】:

    标签: javascript node.js rest twitter rate


    【解决方案1】:

    根据twitter documentation,标准帐户的限制是每个速率限制窗口15个请求,即15分钟。因此,如果您在 15 分钟内发送 22 个请求,则超出了限制。

    标准 API 的速率限制主要基于每个用户 — 或更准确地描述,每个用户访问令牌。如果一个方法 每个速率限制窗口允许 15 个请求,然后它允许 15 个 每个访问令牌每个窗口的请求数。

    使用仅应用程序身份验证时,会确定速率限制 全局用于整个应用程序。如果一种方法允许 15 每个速率限制窗口的请求,然后它允许您发出 15 个请求 每个窗口 - 代表您的应用程序。考虑这个限制 完全独立于每个用户的限制。

    如果您想提高您的限额,请查看premium APIs

    【讨论】:

    • 8 小时内有 22 个请求,所以这里肯定有其他限制?不幸的是,高级 API 是在帐户级别授予的,因此出于我的目的,它不起作用,因为我正在为其他用户构建它。我认为这可能是全球速率限制,但似乎只有收藏夹/创建受到影响。有什么想法吗?
    • 您从未指定您的请求相距多远,所以我假设。如果您希望以最准确的方式回答您的问题,您应该提供所有详细信息。因此,您在 8 小时内只对所有 twitter API 发出了总共 22 个请求?
    • 让我问你这个,如果没有推文被收藏,它会计入配额吗?我的理解是否定的,但完全基于我的转推频率是如何工作的。如果每次返回“你已经转发了这条推文”都计入配额,我会远远超过限制 10 倍。所以奇怪的是,只有收藏/创建受到影响,即使在收藏/创建功能受到速率限制时,转发也能完美无限制地执行。目前每 5 分钟找到 10 条推文,如果满足查询,则执行 RT 或收藏,即查询提及用户。
    • 每个请求都计入配额,Twitter的响应无关紧要。
    • statuses/retweet 和 favorites/create 以相同的频率请求转发,没有阻碍,但收藏似乎更严格一些。一个最喜欢的刚刚经历过,然后下一次尝试又变成了速率限制。然而,转推从未受到速率限制。同样值得注意的是,直到今天,收藏夹才像这样受到速率限制,没有进行任何更改。我想知道他们是否可以在检测到某些自动化后瞄准限制?虽然我已经阅读了自动化标准并且我没有违反任何规定。
    【解决方案2】:

    似乎不一定有任何记录在案的收藏夹/创建特定限制,但是,今天一切似乎都很好。不完全清楚发生了什么,因为Twitter System Status 页面上没有发布任何更新。

    目前对账户的 POST 请求的技术限制是:

    • 直接消息(每日):限制为每天发送 1,000 条消息。推文:每天 2,400 条。每日更新限制进一步细分 半小时间隔的更小限制。转发被视为 推文。更改帐户电子邮件:每小时 4 次。
    • 关注(每日):技术关注限制为每天 1,000 个。请注意,这只是技术帐户限制,并且有 禁止攻击性跟随行为的附加规则。阅读 遵循限制和禁止的行为。
    • 关注(基于账户):一旦一个账户关注了 5,000 个其他账户,额外的关注尝试受限于 特定账户比率。这些限制包括来自所有 设备,包括 Web、移动、电话、API 等。来自所有的 API 请求 根据每小时 API 限制跟踪第三方应用程序。 通过帐户使用多个第三方应用程序的人 因此将更快地达到 API 限制。

    在网站使用量大的时候,这些限制可能会暂时降低。在这种情况下,我们将在 Twitter 状态上发布更新 网站。

    话虽如此,当时的限制似乎有所减少 但未报告。

    此外,有关高级 API 的有用信息,请参阅上面 Marco 的回答。

    GET 速率限制 也可以在 here 找到,并且扩展了一些,但是文档没有说明单个 POST 选项比其他选项受到限制。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2018-11-04
      • 2011-07-04
      • 2013-01-27
      • 2014-08-05
      • 1970-01-01
      • 2013-06-23
      • 2022-08-22
      • 1970-01-01
      相关资源
      最近更新 更多