264
Я думаю, 412 (Precondition Failed), но может быть лучший стандарт?Какой код ответа HTTP-статуса я должен использовать, если в запросе отсутствует требуемый параметр?
Q
Какой код ответа HTTP-статуса я должен использовать, если в запросе отсутствует требуемый параметр?
A
ответ
246
Статус 422 представляется наиболее подходящим на основе spec.
422 (Unprocessable Entity) код состояния означает, что сервер понимает тип содержимого запроса объекта (следовательно, 415 (неподдерживаемый тип носителя) код состояния является несоответствующим), а также синтаксиса объекта запроса (таким образом, код статуса 400 (неверный запрос) не подходит), но не смог обработать содержащиеся в нем инструкции . Например, это условие ошибки может возникнуть, если тело запроса XML содержит правильно сформированные (то есть синтаксически правильные), но семантически ошибочные инструкции XML.
Сообщаем, что неправильный xml является примером плохого синтаксиса (призывая к 400). Строка искаженного запроса кажется аналогичной этому, поэтому 400 не кажется подходящим для хорошо сформированной строки запроса, в которой отсутствует параметр.
UPDATE @DavidV правильно указывает, что эта спецификация предназначена для WebDAV, а не для основного HTTP. Но некоторые популярные API не-WebDAV используют 422 в любом случае из-за отсутствия лучшего кода состояния (see this).
5
Вы можете отправить 400 Bad Request код. Это один из кодов статуса общего назначения 4xx, поэтому вы можете использовать его для обозначения того, что вы намереваетесь: клиент отправляет запрос, в котором отсутствует информация/параметры, которые требуется вашему приложению, чтобы правильно его обработать.
127
Я не уверен, что есть набор стандартный, но я бы использовал 400 Bad Request:
Запрос не может быть понят сервером из-за некорректного синтаксиса. Клиент НЕ ДОЛЖЕН повторять запрос без изменений.
+54
'400 Bad Request' предназначен для указания проблем на уровне протокола, не семантические ошибки. Если мы собираемся заблокировать коды состояния HTTP, чтобы указать ошибки на уровне приложений (а не на уровне протокола), почему бы не пройти весь путь и просто использовать '412'? –
+22
Реализация OAuth 1.0 от Google согласуется с этим ответом. Ответ 400 задается, когда параметры POST отсутствуют или не поддерживаются: http://code.google.com/apis/accounts/docs/OAuth_ref.html – Tom
+1
@ matt-zukowski: «412: Предварительное условие, данное в одном или нескольких из поля запроса-заголовка, оцененные как false, когда они были протестированы на сервере ». из [RFC2616] (http://www.ietf.org/rfc/rfc2616.txt). Если это POST, параметры находятся в корпусе запроса, а не в поля запроса-заголовка. Технически метод GET отправляет его параметры в заголовки запроса, но вместо этого я бы предпочел бы иметь некоторую консистенцию? – toong
23
WCF API в .NET обрабатывает недостающие параметры, возвращая HTTP 404 «Endpoint не найден» ошибка при использовании webHttpBinding.
404 Not Found может иметь смысл, если вы считаете имя метода веб-службы вместе с его сигнатурой параметра. То есть, если вы выставляете метод веб-службы LoginUser(string, string) и запрашиваете LoginUser(string), последний не найден.
В основном это означает, что метод веб-службы, который вы вызываете, вместе с указанной вами сигнатурой параметра не найден.
10.4.5 404 Не найден
Сервера ничего совпадающего с Request-URI не найдено. Нет Указывается, является ли условие временным или постоянным.
400 Bad Request как Gert suggested, остается в силе код ответа, но я думаю, что это, как правило, используется для обозначения проблемы низкого уровня. Его можно легко интерпретировать как искаженный HTTP-запрос, возможно, отсутствующие или недопустимые заголовки HTTP или аналогичные.
10.4.1 400 Bad Request
Запрос не может быть понят сервером из-за некорректного синтаксиса. Клиент НЕ ДОЛЖЕН повторять запрос без изменений .
+0
+1 для 404 Не найдено. –
+0
Это то, что делает CherryPy по умолчанию. –
+0
О том, что при обработке запроса на отправку, где вы принимаете модель и часть модели, отсутствует? В этом случае вы не получите 404. Вместо этого вы получаете модель, которая недействительна, если я не ошибаюсь, и вы должны решить, что делать сейчас. –
2
Можно утверждать, что необходимо использовать 404 Not Found, поскольку указанный ресурс не найден.
+3
Это поведение Java JAX-RS по умолчанию, когда параметр запроса не может быть преобразован в соответствующий тип данных. Я не согласен с этим. Ресурс WAS нашел: параметры запроса предназначены для фильтрации ресурса, а один из фильтров был снабжен неприемлемым значением. Я думаю, что это соответствует 422 Unprocessable Entity ближе всего, и 400 Bad Request второй ближе всего. – Ryan
3
Я часто использую 403 Запрещенную ошибку. Причиной является то, что запрос был понят, но я не собираюсь делать так, как было задано (потому что все не так). Объект ответа объясняет, что не так, поэтому, если ответ представляет собой HTML-страницу, сообщения об ошибках находятся на странице. Если это ответ JSON или XML, информация об ошибке находится там.
От rfc2616:
10,4.4 403 Запрещено
Сервер понял запрос, но отказывается его выполнять.
Авторизация не поможет, и запрос НЕ ДОЛЖЕН повториться.
Если метод запроса не был ГОЛОВЫМ, и сервер хочет сделать
публичным, почему запрос не был выполнен, ему ДОЛЖЕН описать причину отказа в объекте . Если сервер не хочет , сделайте эту информацию доступной для клиента, вместо этого можно использовать код состояния 404
(не найдено).
+3
Звучит неплохо, хотя я бы, естественно, связал это с ошибками, основанными на аутентификации или разрешении. Кроме того, спецификация намекает на это, где говорится: «Если сервер не хочет предоставлять эту информацию клиенту». Кроме того, 404 может быть лучшим вариантом. Я бы направился к 404 или 400, а не к 403. – tonyhb
+11
Это ужасная идея, даже если технически звучит. 403 универсально используется для ответов об отказе автоответчика, и вы будете путать ад с вашими клиентами, если попытаетесь использовать это для указания ошибок параметров. Например, Twitter делает это - 403 используется как при предоставлении неверных учетных данных OAuth, так и при наличии чего-то семантически неправильного в вашем запросе - и это постоянный источник путаницы для клиентов API. –
+0
@ MattZukowski хорошо, это просто неправильно. Спектр говорит, что «Авторизация не поможет», поэтому Twitter не должен отправлять это для недопустимых учетных данных OAuth. – torvin
1
Для интересующихся, Spring MVC (по крайней мере, 3.x) возвращает 400 в этом случае, что кажется мне неправильным.
Я проверил несколько URL-адресов Google (accounts.google.com) и удалил требуемые параметры, и в общем случае они возвращают 404 в этом случае.
Я бы скопировал Google.
+11
Потому что Google делает это автоматически не означает, что Google делает это правильно! – rve
+2
Я согласен, не обязательно «правильно», но иногда то, что правильно, и что разумно, это две разные вещи. В любом случае .. до читателя :) – Neromancer
+0
Некоторые API Google возвращают 400, например. https://github.com/google/google-api-nodejs-client/issues/404 – Dennis
-3
Я бы с 403.
От RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1
403 Forbidden
Сервер понял запрос, но отказывается выполнять его. Авторизация не поможет, и запрос НЕ ДОЛЖЕН повториться. Если метод запроса не был HEAD, и сервер хочет сообщить, почему запрос не был выполнен, ему ДОЛЖЕН описать причину отказа в сущности. Если сервер не хочет предоставлять эту информацию клиенту, вместо этого может использоваться код состояния 404 (Not Found).
Вы должны описать причину отказа в своем ответе. Если вы предпочитаете не делать этого, просто используйте 404.
+2
downvoted, потому что это дублированный ответ.Попробуйте добавить последнее предложение в качестве комментария к более старому ответу, который предлагает использовать 403 – user
1
Я обычно перехожу на 422 (необработанный объект), если что-то в требуемых параметрах не соответствует требуемой конечной точке API (например, слишком короткий пароль), но для отсутствующего параметра я бы пошел на 406 (неприемлемо).
+4
Ну, 406 Неприемлемый используется с заголовком Accept (если сервер не может отправить ответ, который будет понимать клиент). «Ресурс, идентифицированный запросом, способен генерировать объекты ответа, которые имеют характеристики контента, неприемлемые в соответствии с заголовками приема, отправленными в запросе». , Я застрял с 422, так как нет «правильного» выбора с текущей спецификацией: -/ – JakubKnejzlik
5
В одном из наших проектов API мы решили установить 409 статус для некоторого запроса, когда мы не можем заполнить его на 100% из-за отсутствия параметра.
HTTP Status Code «409 Конфликт» был для нас хорошая попытка, потому что это определение требуется включить достаточное количество информации для пользователя, чтобы признать источник конфликта.
Ссылка: w3.org/Protocols/
Так среди прочего ответа, как 400 или 404 мы выбрали 409 для обеспечения потребности в глядя на некоторых заметки в запросе полезного, чтобы создать новый и правильный запрос.
В любом случае наш случай был особым, потому что нам нужно отправить часть данных, если запрос был не совсем корректным, и нам нужно заставить клиента посмотреть сообщение и понять, что было не так в запросе.
В общем, если у нас есть только некоторые недостающий параметр мы идем на и массив недостающих параметров. Но когда нам нужно отправить дополнительную информацию, например, сообщение о конкретном случае, и мы хотим быть уверены, что клиент позаботится об этом, мы отправим сообщение 409
+0
Я также использую 409 для отсутствующего параметра, но я не уверен, что это currect –
IMO Я бы использовал это, когда значение в строке запроса было неправильным, а не когда было добавленное значение или отсутствующее значение. то есть. Ожидание электронной почты и ее значение - «123123» –
@DerekLitz, какой статус вы бы использовали для дополнительного/отсутствующего значения? – Kelvin
Я склонен думать о параметрах GET и POST в качестве сигнатуры метода пути URL, поэтому 404 имеет смысл для меня. В RESTful API, предназначенном для общественного потребления, разумно возвращать отсутствующие/дополнительные параметры. В контексте URL параметры строки запроса обычно важны для идентификации ресурса, а дополнительные или отсутствующие параметры представляют собой ресурс, который не существует, без каких-либо предположений. Конечно, есть компромиссы с надежностью, явным образом, а необязательные параметры делают ресурс потенциально столь же уязвимым для молчаливой ошибки. Тогда есть удобство использования ... –