Thanks guys. Sorry if repetitive.
On Apr 14, 11:02 am, Matt Sanford <[email protected]> wrote: > 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/efa45ceb8... > [3] -http://groups.google.com/group/twitter-development-talk/browse_frm/th... > [4] -http://groups.google.com/group/twitter-development-talk/browse_frm/th... > [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 methodhttp://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!
