[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
Is the cursor parameter usage explained anywhere? Can't find it on the API doc site. On Sep 8, 2009, at 2:10 PM, Alex Payne wrote: It hasn't been deployed yet, but it's still gonna happen. Will update when I know more. On Tue, Sep 8, 2009 at 13:59, Yu-Shan Fung wrote: I remember reading about this a while back. Has this been deployed yet? The wiki doesn't look like it has any info about cursors. Thanks! Yu-Shan On Tue, Aug 4, 2009 at 10:18 AM, Alex Payne wrote: Once we deprecate the page parameter, it will simply be ignored and the method will attempt to return the entire result set. On Sun, Aug 2, 2009 at 15:15, janole wrote: Hi Alex, In two weeks, we'll be addressing this with a change in back-end infrastructure. The "page" parameter will be replaced with a "cursor" does this mean the "page" parameter won't work anymore after the change? What's happening to those calls to the API still containing the "page=x" parameter? Cheers Ole -- Jan Ole Suhr s...@mobileways.de http://twitter.com/janole -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x -- “When nothing seems to help, I go look at a stonecutter hammering away at his rock perhaps a hundred times without as much as a crack showing in it. Yet at the hundred and first blow it will split in two, and I know it was not that blow that did it, but all that had gone before.” — Jacob Riis -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
It hasn't been deployed yet, but it's still gonna happen. Will update when I know more. On Tue, Sep 8, 2009 at 13:59, Yu-Shan Fung wrote: > I remember reading about this a while back. Has this been deployed yet? The > wiki doesn't look like it has any info about cursors. > Thanks! > Yu-Shan > > > > On Tue, Aug 4, 2009 at 10:18 AM, Alex Payne wrote: >> >> Once we deprecate the page parameter, it will simply be ignored and >> the method will attempt to return the entire result set. >> >> On Sun, Aug 2, 2009 at 15:15, janole wrote: >> > >> > Hi Alex, >> > >> >> In two weeks, we'll be addressing this with a change in back-end >> >> infrastructure. The "page" parameter will be replaced with a "cursor" >> > >> > does this mean the "page" parameter won't work anymore after the >> > change? >> > >> > What's happening to those calls to the API still containing the >> > "page=x" parameter? >> > >> > Cheers >> > Ole >> > >> > -- >> > Jan Ole Suhr >> > s...@mobileways.de >> > http://twitter.com/janole >> > >> >> >> >> -- >> Alex Payne - Platform Lead, Twitter, Inc. >> http://twitter.com/al3x > > > > -- > “When nothing seems to help, I go look at a stonecutter hammering away at > his rock perhaps a hundred times without as much as a crack showing in it. > Yet at the hundred and first blow it will split in two, and I know it was > not that blow that did it, but all that had gone before.” — Jacob Riis > -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
I remember reading about this a while back. Has this been deployed yet? The wiki doesn't look like it has any info about cursors. Thanks! Yu-Shan On Tue, Aug 4, 2009 at 10:18 AM, Alex Payne wrote: > > Once we deprecate the page parameter, it will simply be ignored and > the method will attempt to return the entire result set. > > On Sun, Aug 2, 2009 at 15:15, janole wrote: > > > > Hi Alex, > > > >> In two weeks, we'll be addressing this with a change in back-end > >> infrastructure. The "page" parameter will be replaced with a "cursor" > > > > does this mean the "page" parameter won't work anymore after the > > change? > > > > What's happening to those calls to the API still containing the > > "page=x" parameter? > > > > Cheers > > Ole > > > > -- > > Jan Ole Suhr > > s...@mobileways.de > > http://twitter.com/janole > > > > > > -- > Alex Payne - Platform Lead, Twitter, Inc. > http://twitter.com/al3x > -- “When nothing seems to help, I go look at a stonecutter hammering away at his rock perhaps a hundred times without as much as a crack showing in it. Yet at the hundred and first blow it will split in two, and I know it was not that blow that did it, but all that had gone before.” — Jacob Riis
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
What about the XML response format? How will it change?
On 8/4/09 1:16 PM, Alex Payne wrote:
It will be a hash with 'ids' as one of the elements.
On Sat, Aug 1, 2009 at 18:26, Dewald Pretorius wrote:
Alex,
For non-paged calls, will the result set be [1,2,3,...] or will it be
{ids: [1,2,3]} ?
--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
Chiming in: Please do support both methods of access for 'a while" rather than a hard cutover... thx! At least two week would be appreciated... jeffrey greenberg http://www.inventivity.com http://www.tweettronics.com On Aug 4, 10:15 am, Alex Payne wrote: > What our infrastructure team has told me is that they can support both > behaviors for a limited period of time
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
Once we deprecate the page parameter, it will simply be ignored and the method will attempt to return the entire result set. On Sun, Aug 2, 2009 at 15:15, janole wrote: > > Hi Alex, > >> In two weeks, we'll be addressing this with a change in back-end >> infrastructure. The "page" parameter will be replaced with a "cursor" > > does this mean the "page" parameter won't work anymore after the > change? > > What's happening to those calls to the API still containing the > "page=x" parameter? > > Cheers > Ole > > -- > Jan Ole Suhr > s...@mobileways.de > http://twitter.com/janole > -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
It will be a hash with 'ids' as one of the elements.
On Sat, Aug 1, 2009 at 18:26, Dewald Pretorius wrote:
>
> Alex,
>
> For non-paged calls, will the result set be [1,2,3,...] or will it be
> {ids: [1,2,3]} ?
>
> Dewald
>
> On Jul 31, 3:03 pm, Alex Payne wrote:
>> 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 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
>
--
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
What our infrastructure team has told me is that they can support both behaviors for a limited period of time. On Fri, Jul 31, 2009 at 12:06, Isaiah wrote: > > First off, thanks for the heads up and giving us a large lead time. It's > what I asked for in a previous email, and even if you never read that email > and this isn't a response to me at all. I'll say thanks anyway, because > it's great. :-) > But, forgive me if I'm off base, but you're > saying this change is going to happen just like a switch. One minute the > API will behave one way, then next minute the API will behave differently? > Doesn't this level of behavior change merit a bit of a deprecation period where both behaviors function? > After a sudden change any app still using the old behavior is guaranteed to > fail. If the app fixes early then it will fail up until the api change. In > other words, ALL APPS that use this api call WILL be guaranteed to FAIL for > some period of time. That seems like a pretty ugly prospect. > Many api temper this sort of change in behavior by adding a new method call > or a new argument to the method call. And for some period of time letting > both function while marking the old method deprecated, use at the risk of > being abandoned without warning at the next update. This lets apps update > from one functioning call to another functioning call without users > experiencing any downtime. > I understand that some changes might need to be rolled in quickly to avert > infrastructure disaster or to patch security holes, but with 2 weeks notice, > I'm guessing that's not what we're dealing with here. > Isaiah > YourHead Software > supp...@yourhead.com > http://www.yourhead.com > > > On Jul 31, 2009, at 11:09 AM, Arik Fraimovich wrote: > > > > On Jul 31, 9:03 pm, Alex Payne wrote: > > 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. > > What is defined as "large social graphs"? > > -- > Arik Fraimovich > follow me on twitter: http://twitter.com/arikfr > > -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
Graphs of more than several thousand users, following or followed by. On Fri, Jul 31, 2009 at 11:09, Arik Fraimovich wrote: > > > > On Jul 31, 9:03 pm, Alex Payne wrote: >> 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. > > What is defined as "large social graphs"? > > -- > Arik Fraimovich > follow me on twitter: http://twitter.com/arikfr > -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
Hi Alex, > In two weeks, we'll be addressing this with a change in back-end > infrastructure. The "page" parameter will be replaced with a "cursor" does this mean the "page" parameter won't work anymore after the change? What's happening to those calls to the API still containing the "page=x" parameter? Cheers Ole -- Jan Ole Suhr s...@mobileways.de http://twitter.com/janole
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
Alex,
For non-paged calls, will the result set be [1,2,3,...] or will it be
{ids: [1,2,3]} ?
Dewald
On Jul 31, 3:03 pm, Alex Payne wrote:
> 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 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
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
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
--
Pascal Juergens
twitter.com/pascal
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] 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
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
Thanks for the heads-up on this change! Good show. On Jul 31, 3:06 pm, Isaiah wrote: > First off, thanks for the heads up and giving us a large lead time. > It's what I asked for in a previous email, and even if you never read > that email and this isn't a response to me at all. I'll say thanks > anyway, because it's great. :-) > > But, forgive me if I'm off base, but you're saying this change is > going to happen just like a switch. One minute the API will behave > one way, then next minute the API will behave differently? > > Doesn't this level of behavior change merit a bit of a deprecation > period where both behaviors function? > > After a sudden change any app still using the old behavior is > guaranteed to fail. If the app fixes early then it will fail up until > the api change. In other words, ALL APPS that use this api call WILL > be guaranteed to FAIL for some period of time. That seems like a > pretty ugly prospect. > > Many api temper this sort of change in behavior by adding a new method > call or a new argument to the method call. And for some period of > time letting both function while marking the old method deprecated, > use at the risk of being abandoned without warning at the next > update. This lets apps update from one functioning call to another > functioning call without users experiencing any downtime. > > I understand that some changes might need to be rolled in quickly to > avert infrastructure disaster or to patch security holes, but with 2 > weeks notice, I'm guessing that's not what we're dealing with here. > > Isaiah > > YourHead Software > supp...@yourhead.comhttp://www.yourhead.com > > On Jul 31, 2009, at 11:09 AM, Arik Fraimovich wrote: > > > > > > > On Jul 31, 9:03 pm, Alex Payne wrote: > >> 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. > > > What is defined as "large social graphs"? > > > -- > > Arik Fraimovich > > follow me on twitter:http://twitter.com/arikfr
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
First off, thanks for the heads up and giving us a large lead time. It's what I asked for in a previous email, and even if you never read that email and this isn't a response to me at all. I'll say thanks anyway, because it's great. :-) But, forgive me if I'm off base, but you're saying this change is going to happen just like a switch. One minute the API will behave one way, then next minute the API will behave differently? Doesn't this level of behavior change merit a bit of a deprecation period where both behaviors function? After a sudden change any app still using the old behavior is guaranteed to fail. If the app fixes early then it will fail up until the api change. In other words, ALL APPS that use this api call WILL be guaranteed to FAIL for some period of time. That seems like a pretty ugly prospect. Many api temper this sort of change in behavior by adding a new method call or a new argument to the method call. And for some period of time letting both function while marking the old method deprecated, use at the risk of being abandoned without warning at the next update. This lets apps update from one functioning call to another functioning call without users experiencing any downtime. I understand that some changes might need to be rolled in quickly to avert infrastructure disaster or to patch security holes, but with 2 weeks notice, I'm guessing that's not what we're dealing with here. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jul 31, 2009, at 11:09 AM, Arik Fraimovich wrote: On Jul 31, 9:03 pm, Alex Payne wrote: 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. What is defined as "large social graphs"? -- Arik Fraimovich follow me on twitter: http://twitter.com/arikfr
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
On Jul 31, 9:03 pm, Alex Payne wrote: > 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. What is defined as "large social graphs"? -- Arik Fraimovich follow me on twitter: http://twitter.com/arikfr
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
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 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
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
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 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
>
