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 already have the user (by id). If we've already got them, then I don't waste an API call in asking for it again (as I only have so many). If we don't have them, then I ask Twitter for it. If the next person I go through has all the same friends, then I never make an additional REST API requests. I also do this when accessing the Search API, to make sure I have all user profiles (at least in some stage). Unfortunately I have to do this one by screen_name/from_user because the Search API returns different user id numbers (Which I also store so I can match them if I must). I've got nearly 8M twitter user profiles this way so far and its always growing. -dave On Sep 8, 12:41 pm, dizid <glasw...@gmail.com> wrote: > 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 ID and/or screen_name and the > API calls would still be limited. Only the data returned would be (a > little) more... > > But, as it stands, there seems to be no other way to get screen_names > (for friends and or followers) without doing 1 API call for each > person (ID) on the returndata, which amounts to alot of API calls. > > On Sep 5, 5:09 pm, owkaye <owk...@gmail.com> wrote: > > > 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 finally be consistent. No extra calls > > to figure out who the user really is. Users would complain > > until they got used to the fact that they cannot change > > their screen names on a whim anymore, but they will learn to > > deal with it soon enough. > > > Email doesn't just let you change your address whenever you > > feel like it, and I see no reason why Twitter should allow > > screen name changes either ... except that it takes more > > work to standardize the system in this way than to continue > > with what already exists. > > > But with only the screen name as each unique account > > identifier things would certainly be much simpler. Many > > fewer requests to the server. Less data storage. And being > > that Twitter is supposed to be simple this seems like a goal > > worth pursuing, at least from my point of view. > > > Owkaye > > > > >> 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. > > > >> This costs ALOT of API calls and i run into the API > > > >> rate limit fast, especially with many friends. > > > > >> Is there a better way of getting screen_names for > > > >> friends / followers? > > > >> ( Better, meaning in fewer API calls.)