I’d like to call attention to a particular resource’s rate limit, which I believe is too low: GET lists/members.
This resource returns up to 20 user objects per request and does not support a count (or per_page) parameter to fetch more than 20 user objects per request.
A typical use of GET lists/members is to fetch all the members of a list. Lists may contain up to 500 memebers (ignoring @twitter/team and other exceptions, for now), so getting all members of a list—20 at a time—could require up to 25 requests. However, this resource is limited to 15 requests per rate limit window (currently 15 minutes). Fetching all the members of a single list that contains more than 300 members must be done across a 15 minute span. This is unacceptable.
I’d propose that either:
- this resource’s limit be increased to at least 25 (preferably 100) requests per rate limit window, or
- this resource return more than 20 (at least 34, preferably 200) user objects per request via an optional
count parameter.
While I’m on this topic, it’s worth mentioning that the GET statuses/user_timeline resource suffers from the same fundamental problem. According to the documentation, it allows the retrieval of up to 3,200 Tweet objects but is limited to 200 Tweet objects per request and 15 requests per rate limit window. This effectively limits the number of Tweet objects that can be retrieved to 3,000. This may not seem like a significant degradation, but it’s worth keeping in mind that the 3,200 number was an artificial limit to begin with. It’s not uncommon for long-time Twitter users to have significantly more than 3,200 Tweets (e.g. as of this writing, @jack has tweeted 11,785 times). Lowering this limit from 3,200 to (effectively) 3,000 feels like the API is moving in the wrong direction. Ideally, new versions of the API would allow the retrieval of more of a user’s timeline, not less.
