Perhaps a better solution might be the ability to pass multiple IDs to the user/show method so you could retrieve the details of more than one user in one request, maybe with a limit to the maximum you can get in one go.
-Stuart 2009/2/5 Alex Payne <a...@twitter.com>: > > 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=265 and vote >> (click the star) to signal your support. >> >> @dougw >> >> On Feb 5, 11:40 am, jstrellner<jstrell...@urltrends.com> wrote: >> >>> >>> Thanks Alex, >>> >>> I too, would like to see this return userids AND usernames. >>> >>> -Joel >>> >>> On Feb 3, 5:01 pm, Alex Payne<a...@twitter.com> 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 > > -- http://stut.net/
