Rate Limiting

[Stephen Finucane]

I spent a couple of hours over the long weekend drafting a patch to add
rate limiting to the REST API. It's a customized variant of what DRF
provides by default and sets three unstandardized yet widely used
headers [1] in responses:

  X-RateLimit-Remaining
  X-RateLimit-Limit
  X-RateLimit-Reset

As I wrapped this up, I spent a long time trying to determine some sane
default limits to set for anonymous users and authenticated users. In
doing so, I realized they'd have to be very high because we don't
provide anything to minimize the need for polling (webhooks, ETags,
etc.) and that any rate limiting would negatively impact REST API users
alone, because we don't rate limit the XML-RPC API or the web UI.

Despite my suggestions to the contrary [2], I began to think that
maybe, just maybe, we _shouldn't_ include rate limiting in 2.0 and
should instead get that release out the door and work on implementing a
combined caching (via. ETags) and rate limiting solution for 2.1.

Does this sound rational, or am I talking rubbish? Anyone have any
other thoughts on the matter?

Stephen

[1] http://stackoverflow.com/a/16022625/613428
[2] https://lists.ozlabs.org/pipermail/patchwork/2017-April/004217.html