RESTBase API entry points are currently not rate-limited in any way. While generally exposing only cheap entry points is probably the best defense against (accidental) DOS attacks, we will have some entry points or backend services that will be expensive enough to warrant rate-limiting. As a per-entry point configuration option, it might make sense to support specifying limits in the swagger security stanza per entry point.
One issue with rate limiting is the identification of particular clients. IPs are a relatively poor option, as a large number of users (think schools or universities) can use a single NAT setup. IP-based limits can't be very tight for this reason. Better user identification can be provided for authenticated requests. However, the processing of authenticated requests is currently not very efficient (see [RFC](https://www.mediawiki.org/wiki/Requests_for_comment/SOA_Authentication)).
A separate concern is the reliability and performance of the rate limiting solution itself. It should ideally impose a minimal CPU time and latency overhead on the regular request processing. Additionally, it should scale well to a very large number of requests, and should fail gracefully without breaking ongoing requests.
## Candidate backends
- various Redis-backed solutions
- https://www.npmjs.com/package/ratelimiter
- https://www.npmjs.com/package/redis-rate-limiter