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
