I'm curious why you're using followers/ids and then users/show for
each id? I tried using that and using statuses/followers and found
that the total times were in the same ballpark. statuses/followers
requires far fewer api calls if you're interested in user objects.
FYI, I do want to add and say I agree that either method is EXTREMELY
inefficient. Regardless what the argument against pages and for
cursors are...the current implementation is painful from an end user
perspective. Our backend doesn't really care, but our users don't
like to wait 10-30 minutes for a web page to gather a social graph.
I wish instead of a cursor I could get a snapshot id, # of pages and a
page parameter. I don't know how it's implemented, but the ability to
deterministically parallelize the calls - is such a benefit to the end
user. Pages let me do that.
On Oct 15, 9:17 am, Michael Steuer <
mste...@gmail.com> wrote:
> That's great!! I'm currently using the suggested method (get IDs, then do
> users/show for each of them) and it's horrendously slow and cumbersome. It'd
> be great if you could get a 100 user objects at the time, based on 100 ids
> you provide..
>
> On 10/14/09 7:30 PM, "Chad Etzel" <
c...@twitter.com> wrote:
>
>
>
> > I agree. I'm lobbying the team for something like this.
> > -Chad
>
> > On Wed, Oct 14, 2009 at 10:21 PM, Josh Roesslein <
jroessl...@gmail.com> wrote:
>
> >> Yeah we really need a way to bulk request user payloads by giving a list of
> >> IDs.
>