GET 列表/状态 per_page 返回意外结果 [英] GET lists/statuses per_page returning unexpected results

问题描述

我调用lists/statuses方法如下，但是结果与per_page参数不一致.

I'm calling the lists/statuses method as follows, but the results are inconsistent with the per_page parameter.

http://api.twitter.com/1/lists/statuses.xml?slug=wp1906ultras&owner_screen_name=enloes&per_page=20&page=3

在我上面的例子中，per_page = 20，当我得到 page=1 时，我得到 11 个结果.当我得到 page=2 时，我得到 9 个结果，page=3 我得到 12 个结果.如果我将 per_page 设置为 11，我相信我会为 page=1 获得 5 个结果.

In my example above where the per_page = 20, when I get page=1 I get 11 results. When I get page=2, I get 9 results and page=3 I get 12 results. If I set per_page to 11, I believe I get 5 results for page=1.

这对任何人都有意义吗?当然不是对我...

Does this make sense to anyone? Sure doesn't to me...

推荐答案

我们最近宣布将弃用分页以支持使用 since_id 和 max_id 的原因之一是因为很难保证从一项不 & 的服务无法以这种方式组织推文.

One of the reasons we've recently announced that paging will be deprecated in favor of the usage of since_id and max_id is because it's difficult to guarantee accurate paging metaphors from a service that doesn't & can't organize tweets that way.

API 中的所有 count 和 per_page 参数实际上都是最多"参数——您获得的数量不会超过您指定的数量.

All count and per_page parameters in the API are really "up to" parameters -- you'll get no more than the amount you specify.

这篇博文概述了即将弃用的内容:https://dev.twitter.com/blog/api-housekeeping 和 https://dev.twitter.com/docs/working-with-timelines 概述了处理此类时间表的最佳做法.

This blog post outlines the upcoming deprecation: https://dev.twitter.com/blog/api-housekeeping and https://dev.twitter.com/docs/working-with-timelines outlines best practices for working with timelines like these.

我建议不要使用分页比喻，而是使用 since_id 和 max_id 以获得更好的可靠性和长期可行性.

I recommend moving away from using the paging metaphor to the usage of since_id and max_id for better reliability and long-term viability.

这篇关于GET 列表/状态 per_page 返回意外结果的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！