Problem type for exhausted rate limits

[Acconut]

It would be helpful if there was a problem type for when the rate limit is reached and a request is therefore rejected.

I wonder whether such a problem type could be defined in this document. The documentation defines headers to communicate information about rate limits and a problem type for rate limit exhaustion seems related. Of course, the document should not make usage of such a problem type mandatory.

[ioggstream]

While this can be useful, one of the reasons for using headers was to avoid processing content (e.g., de/serializing json) in contexts where throughput was key.

Returning json content consumes resources :)

We can engage with implementers to check if this is needed.

[Acconut]

Such a problem type would be completely optional. Upon reaching rate limits, it's up to the server to decide whether to return an empty 4xx response with the rate limit header or whether to use the problem type in addition to the rate limit headers. The problem type would not replace or repeat the information from the rate limit headers.

I imagine that some API servers want to provide error details in the response body (next to response headers and status code) as this improves developer experience (DX) and makes debugging easier. But at the end of the day, that's up to the server.