Open Ktmi opened 3 months ago
Here's a blueprint for specifying API rate limits.
This document is for how rate limits shall be specified for API endpoints. These rate limits are global, shared across all users, and are meant to be used to address technical constraints. Rate limits will be provided as a list[dict]
, which each enclosed dict containing match
, limit
, and method
attributes.
The value of the limit
attribute determines the rate limit for the matched URLs.
The value of the method
attribute is a list of HTTP methods to rate limit for.
The value of the match
attribute will be used to construct a regular expression which will attempt to match against a URL. Any subgroups of the regex will be used for providing finer rate limit controls, e.g. rate limiting per object ID.
The list of rate limits will be evaluated in sequential order. If a requested URL matches the regular expression and HTTP method, it will then generate a hit on that limit. If the rate limit is exceeded, the server will return code 503, service unavailable. If the rate limit is not exceeded, the request is allowed to go through, without evaluating any more possible matches.
api_rate_limits = [
{
"method": ["GET"],
"match": "`^/switches/(?P<switch_id>\w*)/$`",
"limit": "amount/time unit"
},
...
]
This originates from the discussion in #454. Part of what we want do with rate limits is allow for rate limiting API endpoints. To do so, the simplest mechanism would be implementing some ASGI middleware for rate limiting API requests. There are already existing middleware that for rate limiting api requests that we could use, though they may not be entirely ideal:
slowapi
- Uses thelimits
api, but tools for setting limits on endpoints is fairly limitedasgi-ratelimit
- Better tooling for setting limits on endponts, but uses its own api for the limits themselves, making it difficult to interoperate with other rate limit tools.It may be better to look into implementing our own middleware to merge the parts we like about both sets of tools.