Page MenuHomePhabricator

REST API Rate Limiting
Open, Needs TriagePublic


Not crucial for the Parsoid REST API, but important for REST APIs in general. We need to be able to configure rate limits per client API key, as well as a rate limit for unauthenticated API calls.

We may have different classes of client keys; for example, a bot by a well-known community developer might be granted a higher rate limit.

Event Timeline

EvanProdromou renamed this task from Rate limits to REST API Rate Limiting.Apr 17 2019, 12:02 AM
EvanProdromou created this task.
Anomie added a subscriber: Anomie.Apr 17 2019, 1:46 AM

This sounds like you're thinking of it from a very corporate mindset, versus MediaWiki's traditional rate limiting that generally works on a feature basis (e.g. edits per time) per user account rather than trying to limit a particular "client".

Tgr added a subscriber: Tgr.Apr 19 2019, 5:04 PM

MediaWiki rate limiting is based on user authentication, and often happens deep in the application (for example there are different rate limits for rendering a thumbnail in a standard size and a nonstandard one; the API does not know what are the standard sizes) and is only communicated to the controller in the form of error messages.

In theory there are use cases where user identity and client identity are not the same (more or less the things we use OAuth for). In practice I'm not sure those use cases have any overlap with the use cases where there's a need for rate limiting.

Tgr added a comment.EditedApr 24 2019, 8:46 PM

MediaWiki does lots of tricky rate / volume / timing management things: Throttler/User::pingLimiter, PoolCounter, ChronologyProtector, there are probably other things. At some point we should probably consider if/how the API framework needs to interacts with any of those.