Anyone else still confused at how this works? I'm still confused at how
this is any different than the way it was before with the paging (other than
one-less API call).
Jesse
On Sun, Oct 4, 2009 at 10:57 PM, John Kalucki jkalu...@gmail.com wrote:
If an API is untrusted, it must be treated as
Curious -- why isn't the end of list indicator a reliable enough
indication? Iterate until seems simple and reliable.
Can you request the denormalized count via the API before you begin?
(Not familiar enough with the API, but the back-end store offers this
for all sorts of purposes.) You'd have
John, because no offense, but frankly I don't trust the Twitter API. I've
been burned too many times by things that were supposed to work, code
pushed into production that wasn't tested properly, etc. that I know better
to do all I can to account for Twitter's mistakes. There's no telling if at
the Number of ID's is the number of followers
you also can call
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show
first. Within the result you have
followers_count1031/followers_count
friends_count293/friends_count
however - you have to do an additional API call if you don't
Thomas, again, that number may be different from one minute to another, and
I've also found it gets cached differently. I want to know the number of
friends/followers at the time the snapshot was taken for the set I'm paging
through. I want to know the number Twitter expects to be in that
If an API is untrusted, it must be treated as entirely untrusted. You
should be adding defensive heuristics between the untrusted API
results and your application. If a given fetch seems bad, then queue
the results and don't act on them until otherwise corroborated,
perhaps by some quorum of
