Подходящий код статуса HTTP для POST для создания ресурса, превышающего лимит

Question

Я играл с REST API.Я нашел ошибку, мой POST-запрос использовался для получения ответа с кодом HTTP-401.Хотя ресурс был создан.Это не так, как это должно работать.Это заставило меня думать, что этот API не был лучшим API в мире.

Затем я исправил свой запрос, все выглядело нормально, но затем REST API вернул HTTP-400.Причиной было «превышен лимит ресурсов».

И тут возникает мой вопрос: какой правильный HTTP-код состояния подходит для разрешения ситуации?Я имею в виду, клиент превысил лимит ресурсов, и все же он отправляет запрос POST.Я считаю, что HTTP-400 для неправильно сформированного запроса, но все правильно отформатировано.Разве мы не должны использовать какой-то другой код?Если да, то какой?HTTP-429 Too Many Requests кажется тоже плохим, может быть HTTP-422 Unprocessable Entity?

Answer 1

Какой правильный код статуса HTTP для разрешения ситуации?

Код состояния, как и метод запроса, преднамеренно грубый;мы не пытаемся быть предельно точными в описании проблемы, но в общих чертах описываем общую категорию проблемы, чтобы универсальные клиенты (такие как браузеры и кэши) могли делать правильные вещи, когда этот код виден в ответе (дляпример: вызов диалогового окна входа в систему при наблюдении за 401 Несанкционированным )

Существует ряд деревьев решений, помогающих выбрать подходящий код;Я думаю, что вижу Майкла Копрата чаще всего;они, как правило, не являются исчерпывающими, но обычно охватывают все коды, определенные HTTP - вы можете также использовать регистр кодов для других опций.

Затем я исправил своизапрос, все выглядело хорошо, но затем REST API вернул HTTP-400.Причиной было «превышен лимит ресурсов».

«Ограничение ресурса» мне кажется немного двусмысленным, поскольку предполагаемый смысл может заключаться в том, что размер ресурса слишком велик - другими словами, что длина тела сообщения / длина содержимогослишком большой ( 413 Слишком большая полезная нагрузка может показаться подходящим);в качестве альтернативы, это может быть попытка сообщить, что квота превышена, например: 508 Предел ресурса достигнут .

4xx должен указывать на то, что клиент может исправить - проблема с запросом, а не проблема на хосте.Так что это может быть намек на то, что значение 413 является тем, которое предназначено.

Но если в случае, когда есть проблема в запросе, и ни один из других кодов состояния, кажется, не являетсяmatch, 400 Bad Request is fine .

Подробное объяснение того, что происходит, должно быть представлено в теле сообщения, но это не всегда происходит.

Тело НЕ было слишком большим, тот же запрос, выполненный после удаления одного из ресурсов, получил успешный ответ (поэтому я считаю, что HTTP-400 неверен).

Увлекательно: 4xx Too Many Notes.Я думаю, что вы могли бы привести аргументы в пользу 403 Forbidden и 405 Method Not Allowed , с полезной нагрузкой, которая описывает состояние как временное и предлагает возможные меры.

И действительно ли это ошибка сервера?Не клиент?

По большей части, если клиент может распутать вещи, то вы должны использовать члена 4xx класса статусакоды.