I think changeable screen_names are a big problem even outside the api, for links for example : twitter accounts are linked everywhere with uri http://twitter.com/screen_name so it may cause 404 if the user changes his/her screen_name, or worst if someone else takes it, it will link to the wrong place ! Such links should be very low valued by search engines. This is even not what it's called Unique Ressource Identifier...
On Sep 5, 7:30 pm, owkaye <owk...@gmail.com> wrote: > You've just made a perfect argument for my suggestion that > Twitter use ONLY unchangeable screen names (no more ids) for > the whole system. > > :) > > Owkaye > > > > > 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.xmland 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
