Re: [httpapi] RateLimit Header client implementations

[Alex Martinez <[e-mail]>]

Hi Darrel,

On Wed, Dec 30, 2020 at 3:17 AM Darrel Miller <[e-mail]> wrote:

> [...]
>

>
> From what I understand there are a few scenarios where clients can use
> these headers:
>
>
>
>    1. Optimizing polling frequency:  i.e. check quota and window and
>    determine optimum calling interval
>    2. Prioritization between client tasks:  Don’t let low priority tasks
>    starve high priority tasks of quota
>    3. Enable user agents to avoid hitting rate limit due to some kind of
>    punitive behavior.
>
>
>
> Are you aware of other scenarios?  Are there implementations of these
> scenarios?
>

The scenario about "hitting rate limiting" is quite broad in scope. You can
have rate limits apply per API endpoint, per user identity, per connection,
per time of day, per infrastructure resources, or even per service type or
cost, or a combination of them all - which is quite a bit more than just
limiting some misbehavior.

The immediate benefit of these headers to service providers is being able
to signal expectations to clients so they can adapt. Sometimes it is just a
matter of adjusting to some specific rate of resource consumption. Some
other times the only way to adapt is just to stop using a service entirely
for a while or use another endpoint, and that's more useful than just
returning a 403 or 50X without further information, ie. during a
maintenance window you can use the headers to signal that window with 0
quota units and avoid useless traffic.

I can't think of any other specific scenarios and I don't know yet of
generic client implementations targeting specifically these headers. My
hope is that such clients support just enough of these headers to reap the
main benefits, that is, basic rate limiting information enabling some form
of throttling.

Cheers,
  Alex