This is definitely not the first request for more lenient rate limiting, and we hear you guys. While suggestions like this make a lot of sense, what we're tackling is the underlying problem: the overall cost per request of API calls. We want to reduce that cost across the board so that we can lift rate limits across the board, without a complex set of rules about which parameters do and do not contribute to the hourly limit.
On Sun, Mar 8, 2009 at 10:01, Josh Perry <[email protected]> wrote: > > I wonder if it might be an acceptable compromise for twitter to not > count certain requests against an authenticated user. These request > should theoretically not be much if any more expensive in CPU or > bandwidth than the rate limit check itself. > > I propose that any request with a since_id that does not return any > results not apply to the 100 request/hour limit. > > A request like this would result in a very quick indexed primary key > lookup in the datasource being used to store the data. Also, in the > case that no new items existed there would be no data returned to use > datasource server bandwidth and it would not use any more bandwidth on > the webserver than a 400 rate limit exceeded message. > > Perhaps these request should still be rate limited, but with higher > caps. This would allow developers to provide nearly real-time updates > in our clients without necessitating something extreme like > implementing some Firehose based distribution system. > > Between trying to keep friend-statuses, user-statuses, @replies, > direct messages sent, direct messages received, the following list, > and the followers list all somewhat in sync puts a pretty heavy burden > on the 100 request/hour limit. Especially considering the case where > someone has a multiple clients on a laptop, work desktop, home > desktop, and/or iPhone puts developers in a bit of a predicament. > > Josh > -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
