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

24

Я разрабатываю REST API для проекта, в котором пользователи всегда используют один из нескольких «планов» - каждый план определяет некоторые ограничения ресурсов, например, максимальное количество пользователей, которое может иметь учетная запись, или максимальное количество данных, которые они могут загрузить. После достижения одного из этих ограничений пользователи могут обновить свои планы (по сути, заплатить), чтобы получить больше ресурсов.

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

Кандидаты, ИМХО:

  • 403 Forbidden - однако я хотел бы провести различие между этим случаем и другими случаями, когда у пользователя просто нет разрешения на выполнение этого действия.

  • 401 Unauthorized - не очень хорошая идея, мы используем это для проблем, связанных с аутентификацией.

  • 402 Payment Required - имеет смысл, но я беспокоюсь об использовании нестандартного, но зарезервированного кода состояния

  • Что-то еще менее стандартное, так 423 Lockedкак маловероятно, что мы будем использовать его для чего-то еще в будущем

Другой вариант - использовать что-то очень стандартное, например, 403указать специфику ошибки в теле ответа.

Мне интересно, какой подход, по вашему мнению, будет (а) работать лучше в долгосрочной перспективе и (б) будет более хорошо придерживаться принципов RESTful.

Шеврон
источник
1
Существует HTTP 507 Недостаточно памяти.
CodesInChaos
RFC4331 может быть актуальным, речь идет об ограничении квоты для WebDAV.
CodesInChaos
@CodesInChaos это не должно быть ошибкой 5xx, и хранилище было только примером (реальный проект вообще не о хранилище, это просто хорошая аналогия).
Шеврон
Код состояния ответа HTTP 429 Too Many Requests указывает, что пользователь отправил слишком много запросов за определенный промежуток времени
ExtractTable.com

Ответы:

17

Я думаю, что 403 является единственным разумным ответом, хотя 405 Метод не разрешен или 409 Конфликт может быть приемлемым, я не думаю, что они так же хороши, как 403, который утверждает:

Сервер понял запрос, но отказывается его выполнить. Авторизация не поможет и запрос НЕ ДОЛЖЕН повторяться. Если метод запроса не был HEAD и сервер желает обнародовать, почему запрос не был выполнен, он ДОЛЖЕН описать причину отказа в объекте.

Если вы вернете ошибку 403, она будет содержать некоторую информацию о том, почему ресурсу было отказано - недопустимое разрешение является лишь наиболее распространенным случаем, превышенные пределы не сильно отличаются - у вас нет разрешения, потому что превышен ваш лимит.

gbjbaanb
источник
22

Я считаю 403 неправильным, потому что 403 предназначен для ситуаций, когда вы не получаете доступ к ресурсу, и нет никакого способа получить доступ. Для ваших клиентов, очевидно, есть способ получить доступ: заплатить.

401 действительно неправ, потому что вы используете его не только для аутентификации, но и для этого.

Поскольку вы пишете API, я предполагаю, что кому-то еще придется писать код, который использует API, и этот человек должен прочитать вашу спецификацию API. Вы могли бы пойти с 429 "Слишком много запросов". Обычно он предназначен для ограничения скорости (например, когда клиент может делать 100 запросов в день), но в разумных пределах относится к вашей ситуации. 402 (Требуется оплата) также будет приемлемым, я думаю. Зависит от того, какие инструменты вы ожидаете от людей, чтобы использовать ваш API. 429 рискует, что умный инструмент пытается отправить меньше запросов в минуту / час / день и никогда не удается.

Кстати, согласно https://tools.ietf.org/html/rfc6585, ошибка 429 также должна содержать html-сообщение, описывающее природу проблемы, поэтому есть хороший шанс, что пользователь на самом деле скажет, в чем проблема, если вы предоставите эта информация в вашем ответе.

gnasher729
источник
1
402это вариант, но я предпочитаю зарезервировать 429для целей фактического ограничения ставок, которые мы, вероятно, добавим в будущем
Шеврон
Кажется, Google использует,403 хотя мне нравится 429намного лучше. Я видел несколько пользовательских реализаций http-клиентов, которые делали какие-то странные вещи 401и 403(например, веб-сайт мог бы отключить пользователя, если он когда-либо получал 401 или 403 от API).
Кристиан Враби
0

WebDAV использует для этого HTTP 507 «Недостаточно памяти» и включает дополнительный код ошибки для квоты, превышенной в теле запроса, чтобы отличить его от других видов ограничений хранилища.

CodesInChaos
источник
12
Кажется нелогичным использовать для этого код 5xx.
Бен Ааронсон