Hi Brandon,
You can get the full user objects by paginating the /statuses/
friends method [1]. The ids method was added for the exact cache usage
you describe, but only works well if you need to examine a users
network information (things like followers-in-common). The reason we
returns ids is because we cache that information and it can be
returned very quickly [2]. Returning anything more would essentially
be a very expensive version of the /statuses/friends method … even
just screen names would be expensive. The idea of returning screen
names has come up a few times [3][4][5] but it's not something we can
support and still keep the site running.
Thanks;
— Matt Sanford / @mzsanford
[1] - http://apiwiki.twitter.com/REST+API+Documentation#statuses/friends
[2] -
http://groups.google.com/group/twitter-development-talk/msg/efa45ceb8bed71b4
[3] -
http://groups.google.com/group/twitter-development-talk/browse_frm/thread/2d013e8fc6d9a71e/ef907e1ca06b97ff
[4] -
http://groups.google.com/group/twitter-development-talk/browse_frm/thread/98f4c4d13954e8bf/4b511a0455f8bffe
[5] - http://code.google.com/p/twitter-api/issues/detail?id=265
On Apr 14, 2009, at 09:31 AM, Brandon Geiger wrote:
Right now we are using the method:
http://twitter.com/friends/ids.json
to get a user's friends, but it doesn't have the friend's screen_name,
which is obviously how users identify their friends. So what we are
currently having to do, is store the id's in our database then loop
through and use the method:
http://twitter.com/users/show/<id>.json
to figure out the screen_name associated to the id, and store that in
our system as well. This is a failed system because users can change
their screen names and it burns through API requests to fast.
API DEV TEAM: anyway you guys can add screen_name in the response for
the method http://twitter.com/friends/ids.json?
That would solve this issue.
If I'm missing something obvious, or if anyone has a better approach
please reply. Thanks!
