Я пытаюсь выяснить, какой правильный код состояния должен возвращаться в различных сценариях с помощью API-интерфейса типа REST, над которым я работаю. Допустим, у меня есть конечная точка, которая позволяет делать покупки POST в формате JSON. Это выглядит так:
{
"account_number": 45645511,
"upc": "00490000486",
"price": 1.00,
"tax": 0.08
}
Что я должен вернуть, если клиент отправляет мне «sales_tax» (вместо ожидаемого «налога»). В настоящее время я возвращаю 400. Но я начал сомневаться в этом. Должен ли я действительно возвращать 422? Я имею в виду, что это JSON (который поддерживается) и это действительный JSON, он просто не содержит всех обязательных полей.
rest
http-status-codes
Дэвид С
источник
источник
Ответы:
400 Bad Request теперь может показаться лучшим кодом состояния HTTP / 1.1 для вашего варианта использования.
Во время вашего вопроса (и моего первоначального ответа) RFC 7231 не был чем-то особенным; в этот момент я возразил,
400 Bad Request
потому что RFC 2616 сказал (с акцентом мой):и запрос, который вы описываете, является синтаксически допустимым JSON, заключенным в синтаксически допустимый HTTP, и, следовательно, у сервера нет проблем с синтаксисом запроса.
Однако, как отметил Ли Саферит в комментариях , RFC 7231, который устарел RFC 2616, не включает это ограничение :
Однако до этой переписки (или если вы хотите поспорить о том, что RFC 7231 является только предлагаемым стандартом прямо сейчас),
422 Unprocessable Entity
не кажется неправильным код состояния HTTP для вашего варианта использования, потому что во введении к RFC 4918 говорится:И описание
422
говорит:(Обратите внимание на ссылку на синтаксис; я подозреваю, что 7231 частично устарел и 4918)
Это звучит точно так же, как ваша ситуация, но на случай, если возникли какие-либо сомнения, он говорит:
(Замените «XML» на «JSON», и я думаю, что мы можем согласиться, что это ваша ситуация)
Теперь некоторые будут возражать, что RFC 4918 относится к «HTTP-расширениям для Web-распределенной авторизации и управления версиями (WebDAV)» и что вы (предположительно) ничего не делаете с WebDAV, поэтому не должны использовать его.
Учитывая выбор между использованием кода ошибки в исходном стандарте, который явно не охватывает ситуацию, и кодом из расширения, которое точно описывает ситуацию, я бы выбрал последний.
Кроме того, в разделе 21.4 RFC 4918 содержится ссылка на реестр кодов состояния протокола IANA для передачи гипертекста (HTTP) , где можно найти 422.
Я предполагаю, что для клиента или сервера HTTP вполне разумно использовать любой код состояния из этого реестра, если они делают это правильно.
Но с HTTP / 1.1 у RFC 7231 есть тяга, так что просто используйте
400 Bad Request
!источник
400 Bad Request - правильный код статуса HTTP для вашего варианта использования. Код определяется HTTP / 0.9-1.1 RFC.
http://tools.ietf.org/html/rfc2616#section-10.4.1
422 Unprocessable Entity определяется RFC 4918 - WebDav. Обратите внимание, что есть небольшая разница по сравнению с 400, см. Цитируемый текст ниже.
Чтобы сохранить единый интерфейс, вы должны использовать 422 только в случае ответов XML, а также поддерживать все коды состояния, определенные расширением Webdav, а не только 422.
http://tools.ietf.org/html/rfc4918#page-78
Смотрите также сообщение Марка Ноттингема о кодах статуса:
Как думать о кодах статуса HTTP
источник
The following status codes are added to those defined in HTTP/1.1 [RFC2616].
Чтобы отразить статус на 2015 год:
Поведенческие и ответные коды 400 и 422 будут одинаково восприниматься клиентами и посредниками, так что это на самом деле не имеет конкретного значения, которое вы используете.
Однако я ожидаю увидеть 400 используемых в настоящее время более широко, и, кроме того, пояснения, которые предоставляет спецификация HTTPbis, делают его более подходящим из двух кодов состояния:
Для контекста, HTTPbis - это версия спецификации HTTP / 1.1, которая пытается прояснить области, которые неясны или противоречивы. Как только он достиг утвержденного статуса, он заменит RFC2616.
источник
Пример использования GitHub API
https://developer.github.com/v3/#client-errors
Возможно, копирование из хорошо известных API - это разумная идея:
источник
Правильного ответа нет, поскольку это зависит от того, какое определение «синтаксис» используется для вашего запроса. Самое главное, что вы:
Прежде чем все обрушатся на меня, сказав, что здесь нет правильного или неправильного ответа, позвольте мне немного объяснить, как я пришел к выводу.
В этом конкретном примере вопрос OP касается запроса JSON, который содержит ключ, отличный от ожидаемого. Теперь полученное имя ключа очень похоже, с точки зрения естественного языка, на ожидаемый ключ, но оно строго отличается и, следовательно, не распознается (обычно) машиной как эквивалентное.
Как я уже говорил выше, решающим фактором является то, что подразумевается под синтаксисом . Если запрос был отправлен с типом содержимого
application/json
, то да, запрос синтаксически действителен, потому что это допустимый синтаксис JSON, но не семантически действителен, поскольку он не соответствует ожидаемому. (при условии строгого определения того, что делает рассматриваемый запрос семантически действительным или нет).С другой стороны, если запрос был отправлен с более конкретным пользовательским типом контента
application/vnd.mycorp.mydatatype+json
, например, он точно указывает, какие поля ожидаются, то я бы сказал, что запрос может быть легко синтаксически недействительным, следовательно, ответ 400.В рассматриваемом случае, поскольку ключ был неправильным, а не значением , возникла синтаксическая ошибка, если была спецификация для того, что являются действительными ключами. Если для допустимых ключей не было спецификации или ошибка была со значением , это была бы семантическая ошибка.
источник
https://www.keycdn.com/support/422-unprocessable-entity/
источник
Ваш случай:
HTTP 400
это правильный код состояния для вашего случая с точки зрения REST, поскольку его синтаксически неверно отправлятьsales_tax
вместоtax
, хотя это допустимый JSON. Обычно это применяется большинством серверных структур при отображении JSON в объекты. Однако есть некоторые реализации REST, которые игнорируют новоеkey
в объекте JSON. В этом случае пользовательскаяcontent-type
спецификация для принятия только допустимых полей может быть применена на стороне сервера.Идеальный сценарий для 422:
В идеальном мире 422 является предпочтительным и в целом приемлемым для отправки в качестве ответа, если сервер понимает тип содержимого объекта запроса, и синтаксис объекта запроса является правильным, но не смог обработать данные, поскольку они семантически ошибочны.
Ситуации 400 на 422:
Помните, что код ответа 422 - это расширенный код состояния HTTP (WebDAV). Есть еще некоторые HTTP-клиенты / интерфейсные библиотеки, которые не готовы обрабатывать 422. Для них это так же просто, как «HTTP 422 неверен, потому что это не HTTP» . С точки зрения сервиса, 400 не совсем конкретен.
В корпоративной архитектуре сервисы развертываются в основном на сервисных уровнях, таких как SOA, IDM и т. Д. Они обычно обслуживают несколько клиентов, начиная от очень старого собственного клиента и заканчивая новейшими клиентами HTTP. Если один из клиентов не обрабатывает HTTP 422, возможны варианты, когда клиент просит обновить или изменить код ответа на HTTP 400 для всех. По моему опыту, это очень редко в наши дни, но все еще возможность. Поэтому перед принятием решения о кодах ответа HTTP всегда требуется тщательное изучение вашей архитектуры.
Чтобы справиться с подобной ситуацией, сервисные уровни обычно используют
versioning
или устанавливаютconfiguration
флаг для клиентов строгого соответствия HTTP для отправки 400 и отправки 422 для остальных из них. Таким образом, они обеспечивают поддержку обратной совместимости для существующих потребителей, но в то же время предоставляют возможность новым клиентам использовать HTTP 422.Последнее обновление RFC7321 гласит:
Это подтверждает, что серверы могут отправлять HTTP 400 для недопустимого запроса. 400 больше не относится только к синтаксической ошибке , однако 422 все еще является подлинным ответом, если клиенты могут обработать его.
источник
Во-первых, это очень хороший вопрос.
400 Bad Request - когда в запросе отсутствует важная часть информации
например, заголовок авторизации или заголовок типа контента. Который абсолютно необходим серверу для понимания запроса. Это может отличаться от сервера к серверу.
422 Unprocessable Entity - когда тело запроса не может быть проанализировано.
Это менее серьезно, чем 400. Запрос достиг сервера. Сервер подтвердил, что запрос имеет правильную базовую структуру. Но информация в теле запроса не может быть проанализирована или понята.
например,
Content-Type: application/xml
когда тело запроса - JSON.Вот статья, в которой перечислены коды состояния и их использование в REST API. https://metamug.com/article/status-codes-for-rest-api.php
источник
На самом деле вы должны вернуть «200 OK» и в теле ответа включить сообщение о том, что произошло с опубликованными данными. Тогда ваше приложение должно понять сообщение.
Дело в том, что коды состояния HTTP - это именно так - коды состояния HTTP. И они должны иметь значение только на транспортном уровне, а не на прикладном уровне. Прикладной уровень действительно никогда не должен знать, что используется HTTP. Если вы переключили свой транспортный уровень с HTTP на Homing Pigeons, это никак не должно повлиять на уровень вашего приложения.
Позвольте мне привести не виртуальный пример. Допустим, вы влюбились в девушку, и она любит вас обратно, но ее семья переезжает в совершенно другую страну. Она дает вам свой новый почтовый адрес. Естественно, вы решили отправить ей любовное письмо. Итак, вы пишете свое письмо, кладете его в конверт, пишете ее адрес на конверте, ставите на нем штамп и отправляете его. Теперь давайте рассмотрим эти сценарии
Короче говоря, возвращение «200 OK» не означает, что у серверного приложения есть хорошие новости для вас. Это только означает, что у него есть новости.
PS: код состояния 422 имеет значение только в контексте WebDAV. Если вы не работаете с WebDAV, то 422 имеет то же самое стандартное значение, что и любой другой нестандартный код = которого нет.
источник