Thanks for the notification.

What will this mean for etag checks?
I currently fetch a large number of graphs in regular intervals. Any
check that returns a 304 should incur little cost.

Will I need to crawl all the pages and check for their 304?
If I get a 304 on the first one, can I assume that the rest remains
equally unchanged?


Pascal Juergens

On Jul 31, 7:35 pm, Alex Payne <> 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]
> [2]
> --
> Alex Payne - Platform Lead, Twitter, Inc.

Reply via email to