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

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

Reply via email to