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 wrote:
>
> If an API is untrusted, it must be treated as entirely untrust
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 subse
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 specifi
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
1031
293
however - you have to do an additional API call if you don't trust the
pagewise calls
Jesse Stay schrieb:
> Thomas, I
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
Thomas, I don't see where it gives you the expected number of users.
Originally I thought Alex said that was going to be part of it, but not
seeing it in the docs. I only see ids, next_cursor, and previous_cursor.
On Sun, Oct 4, 2009 at 8:36 AM, Thomas Hübner wrote:
> You can use the socialGraph
You can use the socialGraph method before:
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friends%C2%A0ids
If you have this you have the expected number of users.
Jesse Stay schrieb:
> I was wondering if it might be possible to include, at least in the
> first page, but if it's easier it
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 hav