Правильный код состояния HTTP для неправильного ввода

Что такое оптимальный HTTP-код ответа, когда не сообщается 200 (все в порядке), но ошибка ввода?

Мол, вы отправляете некоторые данные на сервер, и он ответит, что ваши данные неверны

использование 500больше похоже на проблему
с сервером. Использование 200с предупреждением / ошибочным текстом ответа плохо (разрешено кэширование и все не в порядке)
использование 204и возврат ничего не дает , может быть, это хорошо (но хорошо поддерживается?)
использование 404неправильно, если запрошенный путь (сценарий) доступен и в нужном месте

У нас была такая же проблема при создании нашего API. Мы искали код состояния HTTP, эквивалентный InvalidArgumentException. Прочитав исходную статью ниже, мы в конечном итоге использовали следующие 422 Unprocessable Entityсостояния:

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

источник: https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm

Коды, начинающиеся с 4 (4xx), предназначены для ошибок клиента. Может быть 400 (Bad Request) подойдет для этого случая? Определение в http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html гласит:

«Запрос не может быть понят сервером из-за неправильного синтаксиса. Клиент НЕ ДОЛЖЕН повторять запрос без изменений».

В дополнение к спецификации RFC вы также можете увидеть это в действии. Проверьте ответы в Твиттере.

https://developer.twitter.com/en/docs/ads/general/guides/response-codes

409 Conflict может быть приемлемым решением.

Согласно: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса. Этот код разрешен только в ситуациях, когда ожидается, что пользователь сможет разрешить конфликт и повторно отправить запрос. Тело ответа ДОЛЖНО содержать достаточно информации, чтобы пользователь мог распознать источник конфликта. В идеале объект ответа должен включать в себя достаточно информации, чтобы пользователь или пользовательский агент мог решить проблему; однако это может быть невозможно и не требуется.

Документ продолжается примером:

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

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

Если это так, я вернусь "Error: The string is already in the database", 409.

Я полагаю, что именно этого хотел ОП: код ошибки, подходящий для случаев, когда данные не соответствуют критериям сервера.

Согласно приведенному ниже сценарию,

Допустим, кто-то делает запрос на ваш сервер с данными, которые имеют правильный формат, но просто не являются «хорошими» данными. Например, представьте, что кто-то отправил значение String в конечную точку API, которая ожидала значение String; но значение строки содержало данные, занесенные в черный список (например, не позволяющие людям использовать «пароль» в качестве пароля). тогда код состояния может быть 400 или 422?

До сих пор я бы возвратил «400 Bad Request», что, согласно w3.org, означает:

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

Это описание не совсем соответствует обстоятельствам; но если вы идете по списку основных кодов состояния HTTP, определенных в протоколе HTTP / 1.1, это, вероятно, ваш лучший выбор.

Однако недавно кто-то из моей команды разработчиков указал [мне], что популярные API-интерфейсы начинают использовать расширения HTTP, чтобы получить более детализированный отчет об ошибках. В частности, многие API, такие как Twitter и Recurly, используют код состояния «422 Unprocessable Entity», как определено в расширении HTTP для WebDAV. Код состояния HTTP 422 гласит:

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

Возвращаясь к нашему примеру с паролем сверху, этот код состояния 422 кажется гораздо более подходящим. Сервер понимает, что вы пытаетесь сделать; и он понимает данные, которые вы отправляете; это просто не позволит этим данным быть обработанными.

404 - Не найдено - может использоваться для запрашиваемого URI-адреса недействительным или запрашиваемого ресурса, такого как пользователь, не существует.