The term API key appears throughout this document; Does API key refer to (in all cases) the OAuth client ID?
Assuming the above is true, does that mean that there are two categories of rate limits, one that corresponds to the client IDs of authenticated users (or classes of IDs, etc), and one that applies to everyone else (unauthenticated users)?
API Key = OAuth 2.0 client ID
Yes, there is a rate limit for requests that have an OAuth 2.0 client ID associated, and a different limit for all unauthenticated requests.
API Key = OAuth 2.0 client ID
Yes, there is a rate limit for requests that have an OAuth 2.0 client ID associated, and a different limit for all unauthenticated requests.
OK, and the requirements are to limit to N requests per Period, by client ID, and N requests per Period for all unauthenticated requests, correct? In other words: We would have N+1 limits defined, where N was the number of registered client IDs, and where each limit represented a pool of requests that could be made by every client included in that pool (i.e. all anon users, and all clients sharing a comment client ID)? Is this correct?
I think the idea of having classes of client IDs (user story 8) would make it so we would only have X+1 rate limits, where X is the number of classes. Classes might be something like:
- "new" (just registered)
- "normal" (some period of time has passed since registration and/or manual review)
- "preferred" (a developer who's shown a need for more API calls and has gone through a request/review process)
- "paid" (a developer who's paid for more API calls. This is out of scope for this project, but it's how I'd imagine we'd implement the feature).
- "in-house" (One of our official front-end clients, or a batch client like ORES. As close to infinite as we could make it.)
I don't think assigning a rate limit per client ID is a reasonable use of our time. If we feel like we need to set a particular limit for a particular client, we could do that by adding a class with only one member, and setting a limit for that class. If we find ourselves doing that a lot, I'd say we could come back around and add a feature to define a limit per client.
