我一直在尝试获取某个公共（未锁定）推特用户的所有推文。我正在使用 REST API： http://api.twitter.com/1/statuses/user_timeline.json?screen_name=andy_murray&count=200&page=1'
在浏览它允许的 16 页（页面参数）时，可以得到 3200 条推文。但后来我发现此类呼叫的速率限制是每小时 150 个（！！！），这意味着一小时内少于 10 个用户查询（每个 16 页）。（如果您进行身份验证，则允许 350，仍然非常低）
关于如何解决这个问题的任何想法？流式搜索 API 似乎不合适（？），并且有一些 Web 服务似乎确实有这些数据。
谢谢
您可以将请求排队并在速率限制允许的情况下进行发送，也可以将经过身份验证的请求作为多个用户发送。每个用户每小时有 350 个请求。
一种方法是使用流 API（或者更具体的用户流，如果它更适合您的应用程序）开始收集来自目标用户的所有推文，而不必担心传统的速率限制，然后使用 REST API 回填这些用户的历史推文。
当然，您每小时只有 350 个经过身份验证的请求，但如果您全天候运行收割机，那仍然是每天 1,680,000 条推文（350 条请求/小时 * 24 小时/天 * 200 条推文/请求）。
因此，例如，如果您决定每天为每位用户提取 1,000 条推文（5 次 API 调用 @ 每次调用 200 条推文），您每天可以运行 1,680 条用户时间线（每小时 70 条时间线）。然后，在第二天，通过使用每个用户最旧的状态 ID 作为statuses/user_timeline请求max_id中的参数来收集接下来的 1,000 条推文，从您离开的地方开始。
流式 API 将使您及时了解目标用户推文的任何新状态，并且 REST API 调用将很快在大约四天内开始达到 Twitter 对这些用户历史推文的获取限制。之后，您可以通过将其他用户添加到follow列表中来添加其他用户以从流式传输端点继续获取，并且您可以停止为那些已达到最大值的用户获取历史推文，并开始获取新目标组的推文。
搜索 API 似乎适合您的需求，因为您可以搜索屏幕名称。Search API 速率限制高于 REST API 速率限制。