It really irks me that the de facto rate limiting headers mix camel case with the more standard dashes, i.e. RateLimit-Remaining instead of Rate-Limit-Remaining.

It is nice to see some actual progress on this because handling rate limits has always been kind of a mess. I really hope the major gateways pick this up quickly so we do not have to write custom logic for every integration.

Maintainer on the Ky library team here, a popular HTTP client for JavaScript.

We support these headers, but unfortunately there’s a mess of different implementations out there. The names aren’t consistent. The number/date formats aren’t consistent. We occasionally discover new edge cases. The standard is very late to the party. Of course, better late than never. I just hope it can actually gain traction given the inertia of some incompatible implementations.

If you are designing an API, I strongly recommend using `Retry-After` for as long as you can get away with it and only implementing the rate limit headers when it really becomes necessary. Good clients will add jitter and exponential backoff to prevent the thundering herd problem.

Looking at the rfc, I'm not sure I understand the motivation, as it suggests multiple times that a client or intermediary will have to read external documentation:

> Servers MAY choose to return partition keys that distinguish between quota allocated to different consumers or different resources. There are a wide range of strategies for partitioning server capacity, including per user, per application, per HTTP method, per resource, or some combination of those values. The server SHOULD document how the partition key is generated so that clients can predict the key value for a future request and determine if there is sufficient quota remaining to execute the request.

If external documentation is required, why send the header? It seems as though having it in the documentation is generally preferable, rather than something to avoid.