Alex, thanks for the advance notice, and having notification when you're at
the last page will be a huge improvement and help. Does this mean pagination
is now required for that method?
Jesse
On Fri, Jul 31, 2009 at 1:35 PM, Alex Payne <a...@twitter.com> wrote:
>
> The Twitter API currently has two methods for returning a user's
> denormalized "social graph": /friends/ids [1] and /followers/ids [2].
> These methods presently allow pagination by use of a "?page=n"
> parameter; without that parameter, they attempt to return all user IDs
> in the specified set. If you've used this methods, particularly for
> exploring the social graphs of users that are following or followed by
> a large number of other users, you've probably run into lag and server
> errors.
>
> In two weeks, we'll be addressing this with a change in back-end
> infrastructure. The "page" parameter will be replaced with a "cursor"
> parameter, which in turn will result in a change in the response
> bodies for these two methods. Whereas currently you'd receive an array
> response like this (in JSON):
>
> [1,2,3,...]
>
> You will now receive:
>
> {ids: [1,2,3], next_id: 1231232}
>
> You can then use the "next_id" value to paginate through the set:
>
> /followers/ids.json?cursor=1231232
>
> To "start" paginating:
>
> /followers/ids.json?cursor=-1
>
> The negative one (-1) indicates that you want to begin paginating.
> When the next_id value is zero (0), you're at the last page.
>
> Documentation of the new functionality will, of course, be provided on
> the API Wiki in advance of the change going live. If you have any
> questions or concerns, please contact us as soon as possible.
>
> [1] http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friends%C2%A0ids
> [2]
> http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-followers%C2%A0ids
>
> --
> Alex Payne - Platform Lead, Twitter, Inc.
> http://twitter.com/al3x
>
