Ответы:
Состояние 422 кажется наиболее подходящим на основании спецификации .
Код состояния 422 (Unprocessable Entity) означает, что сервер понимает тип содержимого объекта запроса (следовательно, код состояния 415 (Unsupported Media Type) является неподходящим), и синтаксис объекта запроса является правильным (таким образом, 400 (неверный запрос) ) код состояния не подходит), но не удалось обработать содержащиеся в нем инструкции. Например, это условие ошибки может возникнуть, если тело запроса XML содержит правильно сформированные (то есть синтаксически правильные), но семантически ошибочные инструкции XML.
Они утверждают, что неправильно сформированный xml является примером плохого синтаксиса (вызов 400). Неверно сформированная строка запроса выглядит аналогично этому, поэтому 400 не подходит для правильно сформированной строки запроса, в которой отсутствует параметр.
UPDATE @DavidV правильно указывает, что эта спецификация предназначена для WebDAV, а не для основного HTTP. Но некоторые популярные не-WebDAV API все равно используют 422 из-за отсутствия лучшего кода состояния ( см. Это ).
400
более подходящим.
Я не уверен, что есть установленный стандарт, но я бы использовал 400 Bad Request , которые в последней спецификации HTTP (от 2014 года) представлены следующим образом :
6.5.1. ошибка 400, неверный запросКод состояния 400 (неверный запрос) указывает на то, что сервер не может или не будет обрабатывать запрос из-за чего-то, что воспринимается как ошибка клиента (например, синтаксис искаженного запроса, кадрирование неверного сообщения запроса или обманчивая маршрутизация запроса).
400 Bad Request
предназначен для обозначения проблем на уровне протокола, а не семантических ошибок. Если мы собираемся перехватить коды состояния HTTP, чтобы указать ошибки уровня приложения (а не уровня протокола), почему бы не пройти весь путь и просто использовать 412
?
WCF API в .NET ручках недостающие параметры, возвращая HTTP 404
«Endpoint Not Found» ошибка при использовании WebHttpBinding .
Это 404 Not Found
может иметь смысл, если учесть имя метода веб-службы вместе с сигнатурой его параметра. То есть, если вы предоставляете метод веб-службы LoginUser(string, string)
и запрашиваете LoginUser(string)
, последний не найден.
По сути это означает, что метод веб-службы, который вы вызываете, вместе с указанной подписью параметра не найден.
10.4.5 404 Не найдено
Сервер не нашел ничего, соответствующего Request-URI. Не указано, является ли состояние временным или постоянным.
400 Bad Request
, Как и предложил Герт , остается действительным код ответа, но я думаю , что это, как правило , используется для обозначения проблемы низкого уровня. Он может быть легко интерпретирован как неверно сформированный HTTP-запрос, может быть отсутствующим или недействительным HTTP-заголовком или подобным.
10.4.1 400 неправильных запросов
Сервер не может понять запрос из-за неправильного синтаксиса. Клиент НЕ ДОЛЖЕН повторять запрос без изменений.
Вы можете отправить код ошибки 400. Это один из более универсальных кодов состояния 4xx, поэтому вы можете использовать его для обозначения того, что вы намерены: клиент отправляет запрос, в котором отсутствует информация / параметры, которые требуются вашему приложению для правильной обработки.
В одном из наших проектов API мы решили установить статус 409 для какого-то запроса, когда мы не можем полностью заполнить его на 100% из-за отсутствующего параметра.
Код состояния HTTP «Конфликт 409» был для нас хорошей попыткой, поскольку его определение требует включения достаточного количества информации, чтобы пользователь мог распознать источник конфликта.
Ссылка: w3.org/Protocols/
Поэтому среди других ответов, таких как 400 или 404, мы выбрали 409, чтобы обеспечить необходимость просмотра некоторых примечаний в запросе, полезных для настройки нового и правильного запроса.
В любом случае, наш случай был особенным, потому что нам нужно отправить некоторые данные накануне, если запрос не был полностью корректным, и нам нужно заставить клиента посмотреть на сообщение и понять, что было неправильно в запросе.
В общем, если у нас есть только какой-то пропущенный параметр, мы выбираем 400 и массив пропущенных параметров. Но когда нам нужно отправить дополнительную информацию, например сообщение о конкретном случае, и мы хотим быть более уверенными, что клиент позаботится об этом, мы отправим 409
Обычно я выбираю 422 (необработанный объект), если что-то в требуемых параметрах не соответствует требуемой конечной точке API (например, слишком короткий пароль), но для пропущенного параметра я выберу 406 (неприемлемо).
Accept-Language: de
, указывающий, что он будет принимать ответы только на немецком языке, но единственные версии запрашиваемого документа, доступные вашему серверу, представлены на английском или французском языке.) Использование его для указания отсутствующего параметра в запросе является неправильным, согласно определению в спец.
Для интересующихся Spring MVC (по крайней мере, 3.x) возвращает 400 в этом случае, что мне кажется неправильным.
Я протестировал несколько URL-адресов Google (accounts.google.com) и удалил обязательные параметры, и в этом случае они обычно возвращают 404.
Я бы скопировал гугл.
Можно утверждать, что 404 Not Found
следует использовать, поскольку указанный ресурс не может быть найден.
Я часто использую 403 Запрещенную ошибку. Причина в том, что запрос был понят, но я не собираюсь делать то, что просили (потому что все не так). Сущность ответа объясняет, что не так, поэтому, если ответ является HTML-страницей, сообщения об ошибках находятся на странице. Если это ответ в формате JSON или XML, информация об ошибке находится там.
От rfc2616 :
10.4.4 403 Запрещено
Сервер понял запрос, но отказывается его выполнить.
Авторизация не поможет и запрос НЕ ДОЛЖЕН повторяться.
Если метод запроса не был HEAD и сервер желает
обнародовать, почему запрос не был выполнен, он ДОЛЖЕН описать причину отказа в объекте. Если сервер не желает предоставлять эту информацию клиенту,
вместо него можно использовать код состояния 404 (не найден).
Authorization will not help
, что Twitter не должен отправлять это для недействительных учетных данных OAuth.
401 Unauthorized
вместо этого. Тем не менее, вы можете понять, почему они этого не делают, если вы посмотрите описания MDN-документов этих двух кодов, которые очень похожи.
Просто для использования ASP.NET Core в качестве ссылки или примера, ASP.NET Core позволяет создать контроллер с действиями, именно так выглядит действие «Подробности».
// GET: Cars/Details/5
public async Task<IActionResult> Details(int? id)
{
if (id == null)
{
return NotFound();
}
var car = await _context.Cars.FirstOrDefaultAsync(m => m.CarId == id);
if (car == null)
{
return NotFound();
}
return View(car);
}
Если параметр id
не задан, возвращается 404 Not Found.
Вернуть 404 - это означает, что ресурс не может быть найден.
Попробуйте изменить URL-адрес сайта, который содержит идентификатор. Я попробовал несколько:
Все возвращают 404, потому что те разработчики правильно интерпретируют стандарт, а ответ здесь и многие другие - нет!
requestBody
.
Я бы пошел с 403.
Из RFC 2616 - протокол передачи гипертекста - HTTP / 1.1
403 Запрещено
Сервер понял запрос, но отказывается его выполнить. Авторизация не поможет и запрос НЕ ДОЛЖЕН повторяться. Если метод запроса не был HEAD и сервер желает сообщить, почему запрос не был выполнен, он ДОЛЖЕН описать причину отказа в объекте. Если сервер не желает предоставлять эту информацию клиенту, вместо него можно использовать код состояния 404 (не найден).
Вы должны описать причину отказа в своем ответе. Если вы предпочитаете не делать этого, просто используйте 404.