Owkaye,
Well, Twitter would not need to change the system (with id's an
screenname's) because there is a user advantage to being able to
change your screenname.
But, maybe the Twitter API could return both ID and screen_name with
only 1 call to the API.
Programmers can then choose to work with
I've done this this way:
Every time I get a user's data- I store it in my database. Doesn't
matter if its from gardenhose or a REST method. I track various
versions of it and keep all changes (good data warehousing practice).
Then, when I crawl a user's list of friends I ask the database if we
caching is the best answer i have found
On Fri, Sep 4, 2009 at 9:01 PM, dizidglasw...@gmail.com wrote:
Hi,
When i request friends (or followers) from the Twitter API i want to
get the screen_name's based on the id's.
I use users/show for this, inputting the id and getting back de
Do you have any code examples for this? So you basically maintain a
local db of id-to- screen_names? Do you get all of a user's friend/
follower id's and then look up their screen names with individual API
calls? What do you do when a user has more relationships than the API
limit will
Thanks for your replies, I will try to explain my question better:
My goal is to backup my friends (e.g. the people i follow) in a .cvs
file.
I first do an API call to get all friends, like this cfhttp
url=http://twitter.com/friends/ids.json?screen_name=#tu#;
method=get result=output /
This
The ideal solution is for Twitter to change the system and
allow each account to have only one screen name, all the
time, forever, with no changes. Then a separate id value
is not required because all account identification will be
done by the original screen name.
REST and SEARCH would
statuts/friends and status/followers i guess
On Sep 5, 3:01 am, dizid glasw...@gmail.com wrote:
Hi,
When i request friends (or followers) from the Twitter API i want to
get the screen_name's based on the id's.
I use users/show for this, inputting the id and getting back de
screen_name.
