brycebaril
Add metadata to support consumers needing to back off
4 new values are provided to the consumer:
-
limit- the limit before throttling may occur -
rate- the rate of token replenishment -
remaining- the number of tokens remaining -
reset- the time, in milliseconds, when token(s) may be replenished
These are useful for consumers to know so they be respond appropriately to avoid the throttling. e.g. in the case of a web service, these values can map to the following common response headers used for rate limiting:
-
X-RateLimit-Limit/RateLimit-Limit-limit -
X-Rate-Limit-Remaining/Rate-Limit-Remaining-remaining -
X-RateLimit-Reset/RateLimit-Reset/Retry-After-reset. This would need to be converted from millis to seconds by a consumers to be standards compliant but I left it as millis in case the added precision is required. -
X-RateLimit-Rate-rate
This allows one to reproduce similar functionality to the original restify throttle plugin.
It also adds the ability to override the burst, rate, and window parameters independently in the Throttle class. Previously, these parameters could only be overridden together. Now, consumers can specify different values for each parameter when needed.
This was mainly added to ensure that we always have a valid window which is required for the reset metadata to function correctly.
Examples of common APIs that respond with such values for their rate limits:
Related RFCs
- https://www.rfc-editor.org/rfc/rfc7231#section-7.1.3
- https://www.ietf.org/archive/id/draft-polli-ratelimit-headers-02.html
