To clarify, since several people have asked: this pending change does
NOT mean that pagination is required. You can still attempt to
retrieve all IDs in one call, but be aware that this is likely to time
out or fail for users with large social graphs.
On Fri, Jul 31, 2009 at 10:35, 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
>
--
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x
