Какой код ответа HTTP-статуса я должен использовать, если в запросе отсутствует требуемый параметр?

Ответ 1

Статус 422 кажется наиболее подходящим на основе spec.

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

Они заявляют, что неверный xml является примером плохого синтаксиса (призывая к 400). Строка искаженного запроса кажется аналогичной этому, поэтому 400 не кажется подходящим для хорошо сформированной строки запроса, в которой отсутствует параметр.

UPDATE @DavidV правильно указывает, что эта спецификация предназначена для WebDAV, а не для основного HTTP. Но некоторые популярные API-интерфейсы, отличные от WebDAV, все равно используют 422 из-за отсутствия лучшего кода состояния (см. Это).

Ответ 2

Я не уверен, что есть стандартный стандарт, но я бы использовал 400 Bad Request:

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

Ответ 3

API WCF в .NET обрабатывает отсутствующие параметры, возвращая ошибку HTTP 404 "Конечная точка не найдена" при использовании webHttpBinding.

404 Not Found может иметь смысл, если вы рассматриваете имя метода веб-службы вместе с его сигнатурой параметра. То есть, если вы выставляете метод веб-службы LoginUser(string, string) и запрашиваете LoginUser(string), последний не найден.

В основном это означает, что метод веб-службы, который вы вызываете, вместе с указанной вами сигнатурой параметра не может быть найден.

10.4.5 404 Не найдено

Сервер не нашел ничего, что соответствовало бы Request-URI. нет указывается, является ли это условие временным или постоянны.

400 Bad Request, как Герт предложил, остается действительным кодом ответа, но я думаю, что он обычно используется для указания проблем нижнего уровня. Его можно легко интерпретировать как искаженный HTTP-запрос, возможно, отсутствующие или недопустимые заголовки HTTP или аналогичные.

10.4.1 400 Плохой запрос

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

Ответ 4

Вы можете отправить код 400 Bad Request. Это один из кодов статуса общего назначения 4xx, поэтому вы можете использовать его для обозначения того, что вы намерены: клиент отправляет запрос, который содержит недостающую информацию/параметры, необходимые вашему приложению, для правильной обработки.

Ответ 5

В одном из наших проектов API мы решили установить 409 Status для некоторого запроса, когда мы не можем заполнить его на 100% из-за отсутствия параметра.

Код состояния HTTP "409 Conflict" был для нас хорошей попыткой, потому что это определение требуют, чтобы у пользователя было достаточно информации для распознавания источник конфликта.

Ссылка: w3.org/Protocols/

Таким образом, среди других ответов, таких как 400 или 404, мы выбрали 409, чтобы обеспечить необходимость просмотра некоторых заметок в запросе, полезных для настройки нового и правильного запроса.

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

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

Ответ 6

Я часто использую 403 Forbidden ошибку. Причиной является то, что запрос был понят, но я не собираюсь делать так, как было задано (потому что все не так). Объект ответа объясняет, что не так, поэтому, если ответ представляет собой HTML-страницу, сообщения об ошибках находятся на странице. Если это ответ JSON или XML, информация об ошибке находится там.

Из rfc2616:

10.4.4 403 Запрещено

Сервер понял запрос, но отказывается его выполнить.
Авторизация не поможет, и запрос НЕ ДОЛЖЕН быть повторен.
Если метод запроса не был HEAD, и сервер хочет сделать что запрос не был выполнен, ему ДОЛЖНО описать причина отказа в юридическом лице. Если сервер не желает сделать эту информацию доступной для клиента, код состояния 404
(Не найдено).

Ответ 7

Можно утверждать, что a 404 Not Found следует использовать, поскольку указанный ресурс не найден.

Ответ 8

Для тех, кого интересует, Spring MVC (по крайней мере, 3.x) возвращает 400 в этом случае, что кажется мне неправильным.

Я протестировал несколько URL-адресов Google (accounts.google.com) и удалил требуемые параметры, и в этом случае они обычно возвращают 404.

Я бы скопировал Google.

Ответ 9

Я обычно перехожу на 422 (необработанный объект), если что-то в требуемых параметрах не соответствует тому, что требуется конечной точке API (например, слишком короткий пароль), но для отсутствующего параметра я бы пошел на 406 (неприемлемый).

Ответ 10

Я бы пошел с 403.

От RFC 2616 - Протокол передачи гипертекста - HTTP/1.1

403 Запрещено

Сервер понял запрос, но отказывается его выполнять. Авторизация не поможет, и запрос НЕ ДОЛЖЕН повториться. Если метод запроса не был HEAD, и сервер хочет сообщить, почему запрос не был выполнен, ему ДОЛЖЕН описать причину отказа в сущности. Если сервер не желает предоставлять эту информацию клиенту, вместо этого может использоваться код состояния 404 (Not Found).

Вы должны описать причину сбоя в своем ответе. Если вы предпочитаете не делать этого, просто используйте 404.