I was really looking forward to implementing these API methods. After dealing with the pagination for so long, this seemed perfect. Then I realized that I have to call "/users/show" for every user to get the most current bio etc. So instead of making 10 calls for a user with 1,000 followers, I'm now making 1,000 calls for that same user. It won't take long to hit the 20K limit. I suppose I could stagger the user updates, but I really need the current data.
Am I coming at this from the right angle? Does anyone see any flaws in my thinking here? 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/idsand /followers/ids, return the entire list of > numeric userIDsfor 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
