rest — 400 BAD запрос HTTP код ошибки означает?
У меня есть запрос JSON, который я публикую на HTTP-URL.
Должно ли это рассматриваться как 400 где requestedResource поле существует, но "Roman" недопустимое значение для этого поля?
[{requestedResource:"Roman"}]
Должно ли это рассматриваться как 400 где "blah" поле вообще не существует?
[{blah:"Roman"}]
Решение
400 означает, что запрос был искажен. Другими словами, поток данных, отправленный клиентом на сервер, не соответствовал правилам.
В случае REST API с полезной нагрузкой JSON 400 обычно и, я бы сказал, правильно, указывают, что JSON каким-то образом недопустим в соответствии со спецификацией API для сервиса.
По этой логике оба сценария должны быть 400-х годов.
Представьте, что вместо этого это был XML, а не JSON. В обоих случаях XML никогда не пройдет проверку схемы — либо из-за неопределенного элемента, либо из-за неправильного значения элемента. Это было бы плохой просьбой. То же самое здесь.
Другие решения
От w3.org
10.4.1 400 неправильных запросов
Запрос не может быть понят сервером из-за неправильной формы
синтаксис. Клиент НЕ ДОЛЖЕН повторять запрос без
модификаций.
Выбор кода ответа HTTP является довольно простой задачей и может быть описан с помощью простых правил. Единственная сложная часть, о которой часто забывают, это пункт 6.5 из RFC 7231:
За исключением случаев ответа на запрос HEAD, сервер ДОЛЖЕН отправить
представление, содержащее объяснение ситуации ошибки,
и является ли это временным или постоянным состоянием.
Правила следующие:
- Если запрос был успешным, верните код 2xx (3xx для перенаправления). Если на сервере произошла внутренняя логическая ошибка, верните 5xx. Если в запросе клиента что-то не так, верните код 4xx.
- Просмотрите доступный код ответа из выбранной категории. Если у одного из них есть имя, которое хорошо соответствует вашей ситуации, вы можете использовать его. В противном случае просто откройте код x00 (200, 400, 500). Если вы сомневаетесь, отступите к коду x00.
- Вернуть описание ошибки в теле ответа. Для кодов 4xx он должен содержать достаточно информации, чтобы клиент-разработчик мог понять причину и исправить клиента. Для 5xx из соображений безопасности никакие детали не должны быть раскрыты.
- Если клиенту необходимо различать разные ошибки и реагировать на них по-разному, определите машиночитаемый и расширяемый формат ошибок и используйте его везде в своем API. Это хорошая практика, чтобы сделать это с самого начала.
- Имейте в виду, что клиентский разработчик может делать странные вещи и пытаться анализировать строки, которые вы возвращаете, как удобочитаемое описание. И, изменяя строки, вы сломаете таких плохо написанных клиентов. Поэтому всегда предоставляйте машиночитаемое описание и старайтесь не сообщать дополнительную информацию в тексте.
Так что в вашем случае я бы вернул 400 ошибок и что-то вроде этого, если «Roman» получен из пользовательского ввода и клиент должен иметь конкретную реакцию:
{
"error_type" : "unsupported_resource",
"error_description" : "\"Roman\" is not supported"}
или более общая ошибка, если такая ситуация является ошибкой логической ошибки в клиенте и не ожидается, если разработчик не сделал что-то не так:
{
"error_type" : "malformed_json",
"error_description" : "\"Roman\" is not supported for \"requestedResource\" field"}
Ни в том, ни в другом случае «неправильный синтаксис». Это неправильная семантика. Следовательно, ИМХО 400 неуместно. Вместо этого было бы целесообразно вернуть 200 вместе с каким-либо объектом ошибки, таким как { "error": { "message": "Unknown request keyword" } } или что угодно.
Рассмотрим пути обработки клиента. Ошибка в синтаксисе (например, неверный JSON) является ошибкой в логике программы, другими словами, ошибкой какого-то рода, и должна обрабатываться соответствующим образом, например, как 403; другими словами, что-то плохое пошло не так.
Ошибка в значении параметра, с другой стороны, является ошибкой семантики, возможно, из-за плохо проверенного пользовательского ввода. Это не ошибка HTTP (хотя я предполагаю, что это может быть 422). Путь обработки будет другим.
Например, в jQuery я бы предпочел не писать ни одного обработчика ошибок, который бы обрабатывал как 500, так и некоторую семантическую ошибку приложения. Другие фреймворки, Ember for one, также обрабатывают ошибки HTTP, такие как 400 и 500, одинаково как большие полные сбои, требуя от программиста обнаружения происходящего и перехода в зависимости от того, является ли это «настоящей» ошибкой или нет.
С помощью 400 коды состояния для любой другой цели, кроме указания того, что запрос неправильно сформирован, это просто неправильно.
Если полезная нагрузка запроса содержит последовательность байтов, которая не может быть проанализирована как application/json (если сервер ожидает, что формат данных), соответствующий код состояния 415:
Сервер отказывается обслуживать запрос, потому что объект
запрос в формате, не поддерживаемом запрашиваемым ресурсом для
запрошенный метод.
Если полезная нагрузка запроса синтаксически правильна, но семантически неверна, нестандартный 422 Код ответа может быть использован, или стандарт 403 код состояния:
Сервер понял запрос, но отказывается его выполнить.
Авторизация не поможет и запрос НЕ ДОЛЖЕН повторяться.
Подумай об ожиданиях.
Как клиентское приложение, вы ожидаете знать, что что-то не так на стороне сервера. Если сервер должен выдать ошибку, когда blah отсутствует или requestedResource значение неверно, чем 400 ошибка будет уместным.
Сначала проверьте URL, это может быть неправильно, если это правильно, затем проверьте тело запроса, которое вы отправляете, возможная причина — запрос, который вы отправляете, отсутствует правильный синтаксис.
Чтобы уточнить, проверьте наличие специальных символов в строке запроса. Если используется (специальный символ), это является основной причиной этой ошибки.
попробуйте скопировать запрос и проанализировать данные каждого тега.