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
