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 _______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
