Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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
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…
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.
All count and per_page parameters in the API are really “up to” parameters — you’ll get no more than the amount you specify.
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.
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.