如何将 Twitter API 用于超过 REST 速率限制的大型 Web 应用程序

Posted 2023-03-28

【中文标题】如何将 Twitter API 用于超过 REST 速率限制的大型 Web 应用程序

【英文标题】：How to use Twitter API for large web app that exceeds REST rate limits

【发布时间】：2016-01-28 17:10:57

【问题描述】：

我们有一个网页应用程序，其中包含显示用户最近的推文的页面。 REST API 每 15 分钟只允许 180 个请求。因此，即使我们将推文缓存几分钟，一旦我们有几百个用户，我们就会超过速率限制。

项目所有者不希望用户必须提供自己的 API 令牌，而 Twitter 嵌入小部件不符合我们的 UX 要求。所以我正在寻找解决方案。

到目前为止，我想出的最好的是：

建立第二个 Web 应用程序，该应用程序使用 Streaming API 并将收集到的推文保存到主应用程序可以读取的数据库中（呃！） 为 REST api 获得更高的速率限制（不知道这是否现实） 创建大量 Twitter 帐户并使用各个令牌（糟糕！） 向 Streaming API 请求过去的推文（似乎不可能）

希望有更好的方法。

【参考方案1】：

Twitter Embed 小部件不符合我们的用户体验要求

如果这将是一个面向公众的网站，请记住 Twitter wants you to comply with their brand guidelines。

因此，使用官方小部件是最简单的方法。

项目所有者不希望用户必须提供自己的 API 令牌，

为什么不呢？如果您要向人们展示他们自己的推文，大概您需要知道他们的 Twitter 名称？让他们使用 Twitter 登录会给你他们的名字并让你使用 OAuth 令牌。用户只需点击“登录”按钮即可。

启动第二个 Web 应用，该应用使用 Streaming API 并将收集到的推文保存到主应用可以读取的数据库中（呃！）

为什么是“呃”？这正是流式 API 的优势所在 - 实时读取一个或多个用户的推文。

【讨论】：

按以上顺序：1) 我们不会更改 Twitter 品牌。我们只是在缩放等以适应主机环境 2）这是一个漫长的故事。我不完全同意这个决定，所以不会在这里为它辩护。底线是这不是我的问题的可用解决方案。 3) 这当然是 Streaming API 的优点，但实时推文更新不是我们的应用/产品需要的。因此，构建第二个应用程序来存储推文需要大量技术开销，不会为我们的产品增加任何价值。