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

Я думаю, 412 (Precondition Failed), но может быть лучший стандарт?

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

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

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

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

Я не уверен, что есть установленный стандарт, но я бы использовал 400 Bad Request , которые в последней спецификации HTTP (от 2014 года) представлены следующим образом :

6.5.1. ошибка 400, неверный запрос

Код состояния 400 (неверный запрос) указывает на то, что сервер не может или не будет обрабатывать запрос из-за чего-то, что воспринимается как ошибка клиента (например, синтаксис искаженного запроса, кадрирование неверного сообщения запроса или обманчивая маршрутизация запроса).

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 (неприемлемо).

Для интересующихся 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 (не найден).

Просто для использования 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-адрес сайта, который содержит идентификатор. Я попробовал несколько:

• вопрос репозитория gitub
• страница слияния
• вид продукции Amazon
• список ebay
• новостная статья BBC

Все возвращают 404, потому что те разработчики правильно интерпретируют стандарт, а ответ здесь и многие другие - нет!

Я бы пошел с 403.

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

403 Запрещено

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

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