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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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