Hey Alex, any chance of adding a way of looking up the user name to the search api instead then?
On Feb 5, 6:19 pm, Alex Payne <[email protected]> wrote: > The reason why we can provide the list of IDs without any pagination is > that it comes directly from our denormalized list data store, and > requires no joining, either in SQL or at the application layer. As soon > as we pull in data like screen_name that's sitting elsewhere in our > architecture, the response time slows down drastically. > > So while I do understand that it'd be more convenient, my hunch is that > the quality of service for such a method would be intolerable. > > > > dougw wrote: > > For all those wanting id AND username attributes to be returned with > > these new methods, be sure to head over to > >http://code.google.com/p/twitter-api/issues/detail?id=265and vote > > (click the star) to signal your support. > > > @dougw > > > On Feb 5, 11:40 am, jstrellner<[email protected]> wrote: > > >> Thanks Alex, > > >> I too, would like to see this return userids AND usernames. > > >> -Joel > > >> 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
