This is really useful, however would be even more useful if you offered an unrate limited service to return the username for each userid.
Problems I foresee. 1 user uses your web based app and the user has 10k followers and 10k friends and thats your limit used up for the hour. Even with caching using this is pointless for apps with large numbers of users. solutions that would work for me. return the user name as well as userid(yes I know this can change but most people will want to get it, make it optional) or let us use the search api to return user data using a userid like the username. On Feb 5, 3:07 am, James Deville <[email protected]> wrote: > Any chance of a easy way to map this to usernames? We want the friends list > for Witty (and I imagine others), but we don't need full profiles, just this > + username. This won't help us otherwise since we'll need to map the entire > list to usernames, which will require too many requests. > > JD > > On Wed, Feb 4, 2009 at 4:31 PM, Alex Payne <[email protected]> wrote: > > > The response should be ordered with most recent followed/followers first in > > the list. > > > Another developer noted duplicates; we'll look into that. > > > Matt K. wrote: > > >> Alex - > > >> This is a great addition to the API - will make things much easier. > > >> Quick question (and I apologize if this is already documented): do the > >> followers / friends always come in descending order of when they > >> friendship/follow was created? In other words will the most recent > >> follow/friend always be first? > > >> I know the original followers call was ordered in the order in which > >> the follower joined twitter. Hoping this isn't set up the same way - > >> it would be nice to basically stop iterating over the list once a > >> repeat friend/follower is found. > > >> Thanks for the clarification, > >> Matt > > >> On Feb 3, 5:01 pm, Alex Payne<[email protected]> wrote: > > >>> Happy to announce two new API methods today, delivered in response to > >>> developer demand for an easier way to keep tabs on users' social graphs. > >>> The methods, /friends/ids and /followers/ids, return the entire list of > >>> numeric user IDs for a user's set of followed and following users, > >>> respectively. Responses to these methods are cached until the user's > >>> social graph changes. The responses come direct from our denormalized > >>> list data stores, and should be reasonably fast even for users with a > >>> large number of followers/follows. > > >>> These new methods are most useful for services that are maintaining a > >>> cache of user details. If you see a user ID that you don't have cached, > >>> you'll have to call /users/show to retrieve that user's details. But for > >>> services with large user bases, or those that simply want to diff a > >>> user's social graph over time, we hope these methods will come in handy. > > >>> You can find the documentation athttp:// > >>> apiwiki.twitter.com/REST-API-Documentation#SocialGraphMethods. > > >>> -- > >>> Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x > > > -- > > Alex Payne - API Lead, Twitter, Inc. > >http://twitter.com/al3x
