Re: A new HTTP response code for "OK but busy"

 I would just note that there is a huge amount of of
throttling/fallback/retry code already deployed around more or less every
popular API, both server and client side, which relies on 429, and it seems
to work acceptably well.  You’d need to demonstrate a real benefit-at-scale
to make people even consider rebuilding this around a new HTTP status. -T

On Nov 28, 2024 at 3:17:58 AM, Robert Rothenberg <robrwo@gmail.com> wrote:

> It would be nice to detect when the server is unusually busy and
> indicate in the response that the client should retry later, but in a
> way that indicates the response content is not an error.
>
> HTTP 429 (too many requests) and HTTP 503 (server unavailable) are not
> really relevant as they suggest there is an error.
>
> It would be useful to have something like HTTP 229 that means "Ok, but
> busy". The response would include a Retry-After header, and the body
> would be a normal response body as if an HTTP 200 was received.
>
> The meaning of this response is that the content fulfils the request,
> but the server is "busy", and that future requests before the
> Retry-After header might be rejected.
>
> The server is not required to (and should not) explain why it is busy.
> It may be due to high CPU load, high memory usage, or too many requests,
> or too many requests from a specific agent or network.
>
> The client should not infer anything other than the response body is
> useful but to discontinue making additional requests until after the
> recommended time.
>
>
>
>
>