HTTP 400 (неверный запрос) для логической ошибки, а не искаженного синтаксиса запроса

На данный момент последний проект спецификации HTTPbis, предназначенный для замены и сделать RFC 2616 устаревшим, указывает :

На ум приходит статус 422 (RFC 4918, раздел 11.2):

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

HTTPbis будет обращаться к формулировке 400 Bad Request, чтобы охватить также и логические ошибки. Таким образом, 400 будет включать 422.

Из https://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-18#section-7.4.1
«Сервер не может или не будет обрабатывать запрос из-за ошибки клиента (например, неправильного синтаксиса)»

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

Только мои 2 цента ... В наши дни нам нужны юристы и судьи, чтобы интерпретировать язык в RFC :)

Спасибо, Виш

Можно утверждать, что наличие неверных данных в вашем запросе является синтаксической ошибкой, даже если ваш фактический запрос на уровне HTTP (строка запроса, заголовки и т. Д.) Синтаксически действителен.

Например, если веб-служба Restful задокументирована как принимающая POST-запросы с настраиваемым типом содержимого XML application/vnd.example.com.widget+xml, и вместо этого вы отправляете какой-то бессмысленный простой текст или двоичный файл, кажется разумным рассматривать это как синтаксическую ошибку - тело вашего запроса не в ожидаемом виде.

Я не знаю никаких официальных ссылок, подтверждающих это, хотя, как обычно, похоже, что это связано с интерпретацией RFC 2616.

Обновление: обратите внимание на измененную формулировку в RFC 7231 §6.5 .1:

Код состояния 400 (неверный запрос) указывает, что сервер не может или не будет обрабатывать запрос из-за чего-то, что воспринимается как ошибка клиента, например, неверный синтаксис запроса, недопустимое формирование сообщения запроса или обманчивая маршрутизация запроса).

похоже, поддерживает этот аргумент больше, чем теперь устаревший RFC 2616 §10.4.1 который сказал только:

Сервер не может понять запрос из-за неправильного синтаксиса. Клиенту НЕ СЛЕДУЕТ повторять запрос без изменений.

На серверах Java EE возвращается 400, если ваш URL относится к несуществующему «веб-приложению». Это «синтаксическая ошибка»? Зависит от того, что вы подразумеваете под синтаксической ошибкой. Я бы сказал да.

В английском правила синтаксиса предписывают определенные отношения между частями речи. Например, «Боб женится на Мэри» синтаксически правильно, потому что оно следует шаблону {Существительное + Глагол + Существительное}. В то время как «Боб женился на Мэри» было бы синтаксически неверным, {Существительное + Существительное + Существительное}.

Синтаксис простого URL-адреса: {протокол +: + // + сервер +: + порт}. Согласно этому синтаксически правильно "http://www.google.com:80".

Но как насчет «abc: //www.google.com: 80»? Кажется, он следует той же схеме. Но на самом деле это синтаксическая ошибка. Почему? Потому что «abc» не ОПРЕДЕЛЕННЫЙ протокол.

Дело в том, что определение того, есть ли у нас ситуация 400, требует большего, чем анализ символов, пробелов и разделителей. Он также должен распознавать допустимые «части речи».

Это сложно.

Я думаю, нам следует;

1. Возвращать 4xx ошибки только в том случае, если у клиента есть возможность внести изменения в запрос, заголовки или тело, что приведет к успешному выполнению запроса с тем же намерением.

2. Возвращать коды диапазона ошибок, если ожидаемая мутация не произошла, т.е. не произошло DELETE или PUT ничего не изменил. Однако POST более интересен, потому что в спецификации говорится, что его следует использовать либо для создания ресурсов в новом месте, либо просто для обработки полезной нагрузки.

Используя пример из ответа Виша, если запрос направлен на добавление сотрудника Прии в отдел маркетинга, но Прия не найдена или ее учетная запись заархивирована, то это ошибка приложения.

Запрос работал нормально, он попал в правила вашего приложения, клиент все сделал правильно, ETags совпали и т. Д. И т. Д.

Поскольку мы используем HTTP, мы должны отвечать в зависимости от влияния запроса на состояние ресурса. И это зависит от вашего дизайна API.

Возможно, вы это разработали.

PUT { updated members list } /marketing/members

Возврат кода успеха будет означать, что «замена» ресурса сработала; GET на ресурсе отразит ваши изменения, но этого не произойдет.

Итак, теперь вам нужно выбрать подходящий отрицательный код HTTP, и это сложная часть, поскольку коды строго предназначены для протокола HTTP, а не для вашего приложения.

Когда я читаю официальные коды HTTP, эти два выглядят подходящими.

Код состояния 409 (конфликт) указывает, что запрос не может быть выполнен из-за конфликта с текущим состоянием целевого ресурса. Этот код используется в ситуациях, когда пользователь может разрешить конфликт и повторно отправить запрос. Серверу СЛЕДУЕТ генерировать полезную нагрузку, которая включает в себя достаточно информации, чтобы пользователь мог распознать источник конфликта.

А также

Код состояния 500 (внутренняя ошибка сервера) указывает на то, что сервер обнаружил непредвиденное условие, которое помешало ему выполнить запрос.

Хотя мы традиционно считали, что 500 - это необработанное исключение: - /

Я не считаю неразумным придумывать собственный код статуса, если он последовательно применяется и разрабатывается.

С такой конструкцией легче справиться.

PUT { membership add command } /accounts/groups/memberships/instructions/1739119

Затем вы можете разработать свой API так, чтобы он всегда успешно создавал инструкцию, он возвращает 201 Created и заголовок Location, и любые проблемы с инструкцией удерживаются в этом новом ресурсе.

POST больше похож на последний PUT в новое место. POST разрешает любую обработку сообщения сервером, что открывает дизайн, который говорит что-то вроде «Действие успешно завершилось неудачей».

Вероятно, вы уже написали API, который это делает, веб-сайт. Вы ОТПРАВЛЯЕТЕ платежную форму, и она была успешно отклонена из-за неправильного номера кредитной карты.

При использовании POST, возвращаете ли вы 200 или 201 вместе с сообщением об отклонении, зависит от того, был ли создан новый ресурс и доступен для GET в другом месте или нет.

С учетом всего вышесказанного я был бы склонен разрабатывать API-интерфейсы, которым требуется меньше PUT, возможно, просто обновляя поля данных, а действия и прочее, которые вызывают правила и обработку или просто имеют более высокую вероятность ожидаемых сбоев, могут быть разработаны для POST инструкции форма.

В моем случае:

Я получаю 400 неверных запросов, потому что я неправильно установил content-type. Я изменил тип контента, после чего смог успешно получить ответ.

До (проблема):

ClientResponse response = Client.create().resource(requestUrl).queryParam("noOfDates", String.valueOf(limit))
                .header(SecurityConstants.AUTHORIZATION, formatedToken).
header("Content-Type", "\"application/json\"").get(ClientResponse.class);

После (исправлено):

ClientResponse response = Client.create().resource(requestUrl).queryParam("noOfDates", String.valueOf(limit))
                .header(SecurityConstants.AUTHORIZATION, formatedToken).
header("Content-Type", "\"application/x-www-form-urlencoded\"").get(ClientResponse.class);