Рекомендуемый код состояния HTTP REST для «достигнутого лимита запроса»

Я собираю спецификацию для службы REST, часть которой будет включать в себя возможность регулирования пользователей в рамках всей службы, а также для групп или отдельных ресурсов. Точно так же тайм-ауты для них будут настраиваться для каждого ресурса / группы / услуги.

Я просто просматриваю спецификацию HTTP 1.1 и пытаюсь решить, как я сообщу клиенту, что запрос не будет выполнен, потому что он достиг своего предела.

Первоначально я подумал, что клиентский код 403 - Forbiddenбыл один, но это, из спецификации:

Авторизация не поможет и запрос НЕ ДОЛЖЕН повторяться

беспокоило меня.

На самом деле кажется, что 503 - Service Unavailableэто лучше использовать - так как он позволяет передавать время повтора с помощью Retry-Afterзаголовка.

Вполне возможно, что в будущем я могу рассчитывать на «покупку» большего количества запросов через электронную коммерцию (в этом случае было бы неплохо, если бы клиентский код 402 - Payment Requiredбыл завершен!) - но я полагаю, что это также можно сжать в ответ 503.

Как вы думаете, что я должен использовать? Или есть другой, который я не рассматривал?

429 Слишком много запросов

Пользователь отправил слишком много запросов за определенный промежуток времени. Предназначен для использования со схемами ограничения скорости. Этот код был принят в RFC 6585 Дополнительные коды состояния HTTP .

   The 429 status code indicates that the user has sent too many
   requests in a given amount of time ("rate limiting").

   The response representations SHOULD include details explaining the
   condition, and MAY include a Retry-After header indicating how long
   to wait before making a new request...

   Note that this specification does not define how the origin server
   identifies the user, nor how it counts requests.  For example, an
   origin server that is limiting request rates can do so based upon
   counts of requests on a per-resource basis, across the entire server,
   or even among a set of servers.  Likewise, it might identify the user
   by its authentication credentials, or a stateful cookie.

   Responses with the 429 status code MUST NOT be stored by a cache...

В некоторой степени вы можете делать с кодами все, что вам нравится, но я согласен, что вы можете использовать 503или, если хотите 402, без возможности жаловаться, что вы что-то ломаете.

Изменить: пурист может сказать, что вы должны начать с 503, а затем переключаться, как только можно сделать платежи.

Отличное дополнение к этому в комментариях:

4xx указывает на ошибку клиента, которая может быть исправлена ​​с помощью определенных действий, тогда как 5xx указывает на проблему на сервере, которую клиент не может устранить. Таким образом, в вашем случае 4xx является более подходящим, потому что (i) сервер ведет себя точно так, как должен, и (ii) клиент может «исправить» ошибку, замедляя или покупая больше кредитов. Точное разрешение можно указать в теле ответа 429. - Майк Чемберлен 7 часов назад