We should implement some kind of adaptive rate limiting, so clients do not have to hardcode the 1 request per second rule.

One way to do this is by using a few HTTP headers to inform a client how many requests they have remaining, e.g.:

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 59

This seems fairly common (see: http://developer.github.com/v3/#rate-limiting , https://dev.twitter.com/docs/rate-limiting/1.1 , https://www.discogs.com/developers/accessing.html , etc..), and most of these APIs use some kind of limit/remaining scheme. But there are probably alternative ways to communicate a rate limit to a client through HTTP headers, we should probably look at some alternatives as well.

Being able to dynamically tweak these values could help us deal with temporary heavy loads (e.g. enforce a temporary decrease in request rates when one or more servers are out of rotation, etc..).

We should implement these headers ASAP, even if they'd be largely dummy values at first. Because clients are slow to update their software and get the updated versions in the hands of users, we should encourage them to implement using these headers now so we can benefit from it when we do a proper implementation of them in the server later on.