I know there's been a ton of request for a followers/screen_names API,
or a friends/screen_names one for that matter. Right now the only way
of getting all of a user's followers is with http://twitter.com/followers/ids.xml
and that only renders the id's. There's no efficient way of getting
the associated screen_names without doing hundreds/thousands/millions
of calls or running into API rate limits. Twitter has rejected the
creation of a followers/screen_names API due to "performance issues/
concerns". What if I or you want to present our app users with a human
readable list of their followers/friends. I believe the alternative is
a much more performance heavy approach for Twitter. What's to stop me
from creating a 1000 (or more) unique users that my app/service uses
to resolve id's into screen_names? That way I would have hundreds of
thousands of API calls available each hour and could easily create a
locally cached db of id-to-screen_name pairs. And of course I would
have to recheck all of them every few days or so to account for
screen_name changes, since there isn't an API for that either. All of
this would result in millions of API calls a day, just to do something
that Twitter could enable with one simple API... Hell, I could
register a hundred thousand users, and create a service that maintains
an id-to-screen_name pair db for Twitter's entire userbase and make it
available to the dev community as a service to work around this
issue... What do you think? Wouldn't it be much easier and beneficial
to Twitter to enable this simple API that many of us have been asking
for for so long now?
I look forward to you thoughts...
Michael
