Рекомендований код статусу HTTP для відповіді "Ліміт плану перевищено"

Я розробляю API REST для проекту, де користувачі завжди перебувають на одному з декількох "планів" - кожен план визначає деякі обмеження ресурсів, наприклад, максимальну кількість користувачів, яку може мати обліковий запис, або максимальну кількість даних, які вони можуть завантажувати. Після досягнення однієї з цих меж користувачі можуть оновити свої плани (по суті оплатити), щоб отримати більше ресурсів.

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

Кандидати, IMHO:

• 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 ризикує, що розумний інструмент намагається надсилати менше запитів за хвилину / годину / день і ніколи не вдається.

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

WebDAV використовує для цього недостатнє сховище HTTP 507 і включає додатковий код помилки для перевищення квоти в тілі запиту, щоб відрізнити його від інших видів обмежень зберігання.