Dewald, it should be noted that, of course, not all 200 request responses are created equal and just because pulling down a response body with hundreds of thousands of ids succeeds, it doesn't mean it doesn't cause a substantial strain on our system. We want to make developing against the API as easy as is feasible but need to do so in a spirit of reasonable compromise.
On Mon, Jan 4, 2010 at 5:59 PM, Dewald Pretorius <dpr...@gmail.com> wrote: > Wilhelm, > > I want the API method to "return the full social graph in as few API > calls as possible." > > If your system can return up to X ids in one call without doing a 502 > freak-out, then continue to do so. For social graphs with X+n ids, we > can use cursors. > > On Jan 4, 6:07 pm, Wilhelm Bierbaum <wilh...@twitter.com> wrote: > > Can everyone contribute their use case for this API method? I'm trying > > to fully understand the deficiencies of the cursor approach. > > > > Please don't include that cursors are slow or that they are charged > > against the rate limit, as those are known issues. > > > > Thanks. > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
