在twitter搜索API中分页+ next_page的目的是什么？ - 他们不会像预期的那样绕过数据。
我正在尝试使用搜索API，并注意到以下查询会超时更改。 此网址是从搜索API“next_page”返回的。
在趋势主题上点击刷新，您会注意到该页面不是常量。
在热门话题中迭代所有15个页面时，您会在每个页面的前几个项目上重复这些内容。
如果您正在聚合数据，那么分页变量+ next_page似乎毫无用处。在热门话题的几分钟内，第1页将是第3页。因此，您最终会在每个页面的1-3个项目上重复，因为新数据会将页面向下推。
避免这种情况的唯一方法是使用 NOT 使用next_page和/或参数，如下所述：
https://dev.twitter.com/discussions/3809
我将现有结果集中最旧的id作为max_id传递。我做 没有通过一页。
哪种方法更适合汇总数据？
我可以使用next_page但跳过已经处理过15页的状态。
或
仅使用max_id并跳过已处理的
==============
答案 0 :(得分：2)
在http://dev.twitter.com/docs/working-with-timelines推特的“使用时间表”文档中，建议使用max_id参数优先于尝试逐页浏览时间轴。