I don't know all the details, but my general understanding is that these bulk followers calls have been heavily returning 503s for quite some time now, and this is long established, but bad, behavior. These bulk calls are hard to support and they need to be moved over to some form of practical pagination scheme. Ideally, we'd offer a stream of social graph deltas on the Streaming API and this polling business could be tightly restricted.
Bluntly, until further back-end work is in place, we can return 5k followers reliably from the third system, or we can attempt to return large result sets, but often throw 503s -- really, timeouts, from the second system. We cannot return bulk operations, or use row-based cursors, from the third system. Scraping the social graph is certainly valuable in some cases, but generally it's a low value proposition for users, and scraping is often is used to support abusive behavior. -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. On Sep 7, 9:27 pm, "David W." <[email protected]> wrote: > Hi John, > > On Sep 6, 3:59 pm, John Kalucki <[email protected]> wrote: > > > resources. There is minor pagination jitter in one case and a certain > > class of row-count-based queries have to be deprecated (or limited) > > and replaced with cursor-based queries to be practical. For now, we're > > sending the row-count-queries queries back to the second system, which > > is otherwise idle, but isn't consistent with the first or third > > system. > > I am getting several emails per day at the moment from users telling > me my app's results are wrong. The application currently asks for the > entire follower/following ID list at once, using /followers/ids and / > friends/ids. Does this count as a "row-count-query"? > > David
