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.)

Reply via email to