http://code.google.com/p/twitter-api/issues/detail?id=1078
On Fri, Oct 23, 2009 at 7:52 AM, Harshad RJ <harshad...@gmail.com> wrote: > Hi, > > I am collating the thoughts in this thread [1] into a proposal to improve > the efficiency of social-graphing applications. > > A common API access pattern for social-graphing applications seems to be: > > 1. Get the friend/follower ids of a user with [*friends/ids*] or [* > followers/ids*] > 2. Get user details one at a time with [*users/show*] > > (This approach saves on bandwidth by not using the [*statuses/friends*] > method, as that would return redundant info when traversing a network) > > Now, since [*users/show*] is not a paginated API, it is easily possible to > save bandwidth and connection overhead by clubbing multiple requests in one > call. For a social-graphing application, the amount of user information > needed is minimal. > > For example, the following amount of information would be sufficient for my > application [1]: > > <?xml version="1.0" encoding="UTF-8"?> > <user> > <id>1401881</id> > <screen_name>dougw</screen_name> > <followers_count>1031</followers_count> > <friends_count>293</friends_count> > <created_at>Sun Mar 18 06:42:26 +0000 2007</created_at> > <statuses_count>3390</statuses_count> > <status> > <created_at>Tue Apr 07 22:52:51 +0000 2009</created_at> > </status> > </user> > > This is significantly smaller than the data returned by [*users/show*]. > > To prevent misuse of the new API the following could be enforced: > 1. A maximum limit on number of users that can be queried in one request > 2. Rate limiting based on number of users requested. For example, if (N) > users' details were requested in one call, count it as (N/2) requests. This > will provide incentive for using the new API as well as dettering misuse. > > > [1] > http://groups.google.com/group/twitter-development-talk/browse_thread/thread/738e9157cf03adc7 > [2] http://twinkler.in > > > cheers, > -- > Harshad RJ > http://hrj.wikidot.com >
