Где я могу найти подробную документацию о том, что НЕ охватывается кодом состояния 200?

Question

Сегодня у нас было обсуждение операции передачи, в результате которой был получен код состояния 200, хорошо. Было возвращено два объекта, выглядящих так.

Первый достаточно понятен (и следует ожидаемому контракту).

{ name: "john", age: 34, city: "stockholm" }

Второй, следующий за контрактом, но с явно неверными данными.

{ name: null, age: -3.141526, city: "http://some.com/address/poof" }

Одна сторона утверждала, что код состояния 200 неверен, поскольку значения неверны. Другая сторона утверждала, что код состояния описывает операцию как таковую и формат запроса / ответа, который прошел хорошо, поскольку передача согласуется с контрактом.

Совершенно очевидно, что конечная точка REST получает исключение из источников, из которых она получает данные. Итак, первая сторона хотела, чтобы результат был 404 не найден или 500 внутренняя ошибка. Другая сторона была открыта для него при условии, что в первом случае структура объекта пуста (полностью равна нулю), а во втором случае она не пытается следовать согласованному формату.

Проверяя Камасутру, говорят, что:

Запрос успешно выполнен. Информация, возвращаемая с ответом, зависит от метода, используемого в запросе.

Теперь, технически говоря, мы не можем точно знать, имеет ли запрошенный ресурс имя, может ли он быть рожден в PI годах и находится ли он в городе, который изменил свое имя на URL. Это на самом деле возможно, хотя и маловероятно. Тем не менее, я хотел бы видеть явное заявление о том, что не включено в код состояния 200.

Вопрос: допустимо ли запрашивать код состояния 400 или выше, потому что значения кажутся (или даже очевидно) неверными?

Answer 1

Не используйте RFC 2616

RFC 2616 в настоящее время совершенно не имеет значения, когда его заменили набором новых RFC, которые вместе определяют протокол HTTP/1.1:

• RFC 7230: HTTP/1.1: синтаксис и маршрутизация сообщений
• RFC 7231: HTTP/1.1: семантика и контент
• RFC 7232: HTTP/1.1: условные запросы
• RFC 7233: HTTP/1.1: Запросы диапазона
• RFC 7234: HTTP/1.1: кеширование
• RFC 7235: HTTP/1.1: аутентификация

Коды состояния

Коды состояния HTTP см. В RFC 7231. Такой документ определяет, что указывает каждый код состояния. Выберите тот, который лучше всего дает результат попытки понять и удовлетворить запрос.

Этот документ также определяет классы кодов состояния, которые помогают определить наиболее подходящий статус для ответа:

Первая цифра кода состояния определяет класс ответа. Последние две цифры не имеют никакой роли классификации. Для первой цифры есть пять значений:

• 1xx (Информационный): запрос получен, процесс продолжается

• 2xx (Успешно): запрос был успешно получен, понят и принят

• 3xx (Перенаправление): необходимо выполнить дальнейшие действия для выполнения запроса

• 4xx (Ошибка клиента): запрос содержит неверный синтаксис или не может быть выполнен

• 5xx (Ошибка сервера): серверу не удалось выполнить явно допустимый запрос

Просто имейте в виду, что коды состояния HTTP являются расширяемыми. RFC 7231 не включает коды состояния расширения, определенные в других спецификациях. Полный список кодов состояния поддерживается IANA.

Необработанный объект

2xx Класс кода состояния указывает, что запрос был успешно получен, понят и принят. Как только вы не примете недействительные данные, то есть объект, который не может быть обработан сервером, 200 Код состояния не подходит для этой ситуации.

422 Код состояния - это то, что вы ищете: синтаксис полезной нагрузки запроса действителен, но не может быть обработан из-за неверных данных. Посмотри:

11.2. 422 необработанного объекта

422 Код состояния (Unprocessable Entity) означает, что сервер понимает тип содержимого объекта запроса (следовательно, 415 (Неподдерживаемый тип носителя) код состояния не подходит), и синтаксис объекта запроса является правильным (таким образом, 400 (Неправильный запрос) код состояния не подходит), но не удалось обработать содержащиеся в нем инструкции. Например, это условие ошибки может возникать, если тело запроса XML содержит правильно сформированные (то есть синтаксически правильные), но семантически ошибочные инструкции XML.

^{Для вашей ситуации просто прочитайте JSON вместо XML.}

422 зарегистрирован в IANA и определен в RFC 4918, документе, определяющем WebDAV, расширение для протокола HTTP.

Диаграммы решений

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

Начни здесь:

Выбор 2xx а также 3xx коды состояния:

Выбор 4xx коды состояния:

Выбор 5xx коды состояния: