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

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

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

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

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

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

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

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

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

web-services rest http

— Андрас Золтан
источник

Ответы:

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...

— Шон Макмиллан
источник

Звучит потрясающе - я буду иметь это в виду! Это идет со свободными кошками? Или они являются расширением протокола?

— Андрас Золтан

HTTP Status кошки - для всех ваших потребностей статуса: flickr.com/photos/girliemac/sets/72157628409467125

— Шон Макмиллан

это только что пошло вокруг офиса к большому смеху и аплодисментам - гений!

— Андрас Золтан

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

— Андрас Золтан

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

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

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

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

— Marcin
источник

503! 503! 503! Достигнут лимит, следующий звонок запрещен.

— Просто и ясно

@YannisRizos: Ах, но это не запрещено после оплаты!

— Марцин

Код ошибки представляет результат одного запроса. Если оплата была произведена, то при последующем запросе все идет как обычно ... Если вы документируете поведение, я в порядке. Или вы можете просто вернуть 200 с сообщением об ошибке. Но это не красиво. Хотя некоторые могут сказать, что использование кодов ошибок HTTP для бизнес-логики не очень красиво. Что ж, я бы лично пошел с 503, сервис в данный момент недоступен - пока, конечно, 402 обычно не поддерживается.

— Яннис

@YannisRizos (и Марцин) - спасибо за ваши комментарии - я подумал, что 503 - лучший вариант; в то же время понимая, что реализации типа RESTful часто могут быть не в порядке, когда дело касается использования кодов состояния HTTP. Моя личная точка зрения на это состоит в том, чтобы использовать то, что обеспечивает протокол, если он не подходит (что на самом деле очень редко). В этом случае, это точно!

— Андрас Золтан

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

— Майк Чемберлен