Какой код состояния HTTP ответа следует использовать, если в запросе отсутствует обязательный параметр?
Я думаю, 412 (предварительное условие не выполнено), но может быть лучший стандарт?
10 ответов
статус 422 кажется наиболее подходящим на основе spec.
код состояния 422 (Unprocessable Entity) означает сервер понимает тип содержимого сущности запроса (следовательно, a 415 (неподдерживаемый тип носителя) код состояния неуместен), и синтаксис сущности запроса правильный (таким образом, 400 (плохой запрос) код состояния не подходит), но не удалось обработать содержащиеся инструкции. Например, эта ошибка состояние может возникнуть, если XML тело запроса содержит хорошо сформированные (т. е. синтаксически правильные), но семантически ошибочные, XML-инструкции.
Они утверждают, что искаженный xml является примером плохого синтаксиса (вызов 400). Искаженная строка запроса кажется аналогичной этому, поэтому 400 не подходит для хорошо сформированной строки запроса, в которой отсутствует параметр.
обновление @DavidV правильно указывает, что этот спек для WebDAV, не основной HTTP. Но некоторые популярные API не-WebDAV используют 422 в любом случае, из-за отсутствия лучшего кода состояния (посмотреть этот).
Я не уверен, что есть стандартный набор, но я бы использовал 400 Bad Request:
запрос не может быть понят сервер из-за неправильного синтаксиса. Клиент не должен повторять запрос без изменений.
на WCF API в .NET обрабатывает отсутствующие параметры, возвращая HTTP 404 ошибка "конечная точка не найдена" при использовании webHttpBinding.
на 404 Not Found может иметь смысл, если вы рассматриваете имя метода веб-службы вместе с его сигнатурой параметра. То есть, если вы предоставляете метод веб-службы LoginUser(string, string) и требованию LoginUser(string), последний не найден.
в основном это означает, что метод веб-службы, который вы вызываете, вместе с указанным вами параметром сигнатура не может быть найдена.
10.4.5 404 Не Найдена
сервер не нашел ничего, что соответствовало бы запросу-URI. Нет указывается, является ли данное условие временным или постоянный.
на 400 Bad Request, as Герт предложил, остается допустимым кодом ответа, но я думаю, что он обычно используется для обозначения проблем более низкого уровня. Его можно легко интерпретировать как неправильный HTTP-запрос, возможно, отсутствующие или недопустимые HTTP-заголовки или аналогичные.
10.4.1 400 Неверный Запрос
запрос не может быть понят сервером из-за неправильного синтаксис. Клиент не должен повторять запрос без варианта исполнения.
обычно я иду на 422 (необработанный объект), если что-то в требуемых параметрах не соответствует тому, что требуется конечной точке API (например, слишком короткий пароль), но для отсутствующего параметра я бы пошел на 406 (неприемлемо).
в одном из наших проектов API мы решили установить статус 409 для некоторого запроса, когда мы не можем полностью заполнить его на 100% из-за отсутствия параметра.
код состояния HTTP "409 конфликт" был для нас хорошей попыткой, потому что это определение требовать включения достаточной информации для распознавания пользователем источник конфликта.
ссылка:w3.org/Protocols/
Так среди другого ответа Как 400 или 404 мы выбрали 409 к принудительно необходимо просмотреть некоторые заметки в запросе, чтобы настроить новый и правильный запрос.
в любом случае наш случай был особенным, потому что нам нужно отправить некоторые данные eve, если запрос не был полностью правильным, и нам нужно заставить клиента посмотреть на сообщение и понять, что было неправильно в запросе.
В общем, если у нас есть только некоторые отсутствующие параметры заходим 400 и массив отсутствующего параметра. Но когда нам нужно отправить дополнительную информацию, например, сообщение о конкретном случае, и мы хотим быть более уверенными, что клиент позаботится об этом, мы отправляем 409
вы можете отправить 400 плохой код запроса. Это один из более общих кодов статуса 4xx, поэтому вы можете использовать его для обозначения того, что вы намереваетесь: клиент отправляет запрос, в котором отсутствует информация/параметры, необходимые вашему приложению для его правильной обработки.
Я часто пользуюсь ошибку 403 Forbidden. Причина в том, что просьба была понята, но я не собираюсь делать так, как меня попросили (потому что все неправильно). Объект response объясняет, что не так, поэтому, если ответ является HTML-страницей, сообщения об ошибках находятся на странице. Если это ответ JSON или XML, информация об ошибке находится там.
10.4.4 403 запрещено
сервер понял запрос, но отказываясь выполнять его.
Разрешение не поможет, и запрос не должен повторяться.
Если метод запроса не был HEAD и сервер желает сделать
общественность, почему запрос не был выполнен, он должен описать причина отказа в организации. Если сервер не желает сделать эту информацию доступной для клиента, код состояния 404
(Не найдено) может использоваться вместо этого.
можно утверждать, что A 404 Not Found должна использоваться, так как указанный ресурс не может быть найден.
для тех, кто заинтересован, Spring MVC (3.x по крайней мере) возвращает 400 в этом случае, что кажется мне неправильным.
я протестировал несколько URL-адресов Google (accounts.google.com) и удалены необходимые параметры, и они обычно возвращают 404 в этом случае.
Я бы скопировал Google.
Я бы пошел с 403.
с RFC 2616 - протокол передачи гипертекста -- HTTP / 1.1
403-запрещено
сервер понял запрос, но отказывается выполнять его. Разрешение не поможет, и запрос не должен повторяться. Если метод запроса не был HEAD и сервер желает опубликовать, почему запрос не был выполнен, он должен описать причину отказа в сущность. Если сервер не желает предоставлять эту информацию клиенту, можно использовать код состояния 404 (не найден).
вы должны описать причину неудачи в своем ответе. Если вы предпочитаете не делать этого, просто используйте 404.