Запропонований код статусу 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 годин тому