Який код відповіді статусу HTTP я повинен використовувати, якщо в запиті відсутній необхідний параметр?

Я думаю, що 412 (попередня умова не вдалася), але може бути кращий стандарт?

Статус 422 видається найбільш підходящим на основі специфікації .

Код стану 422 (Unprocessable Entity) означає, що сервер розуміє тип вмісту об'єкта запиту (отже, код статусу 415 (непідтримуваний тип медіа) неприйнятний), і синтаксис об'єкта запиту є правильним (таким чином, 400 (поганий запит) ) код статусу невідповідний), але не вдалося обробити містяться інструкцій. Наприклад, ця умова помилки може виникнути, якщо орган запиту XML містить добре сформовані (тобто синтаксично правильні), але семантично помилкові інструкції XML.

Вони заявляють, що неправильно сформований xml є прикладом поганого синтаксису (вимагає 400). Неправильно сформована рядок запиту здається аналогічною цьому, тому 400 не здається підходящим для добре сформованої рядки запитів, у якій відсутній параметр.

UPDATE @DavidV правильно вказує, що ця специфікація призначена для WebDAV, а не основного HTTP. Але деякі популярні API, які не WebDAV, так чи інакше використовують 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 (account.google.com) та видалив необхідні параметри, і вони, як правило, повертають 404 у цьому випадку.

Я б скопіював Google.

Можна стверджувати, що a 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 repo
• сторінка злиття
• перегляд продукту Amazon
• лістинг на ebay
• Стаття новин BBC

Всі повертаються 404, тому що ті розробники правильно інтерпретують стандарт, на що тут відповіді та багатьох інших немає.

Я б пішов з 403.

Від RFC 2616 - протокол передачі гіпертексту - HTTP / 1.1

403 Заборонено

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

У своїй відповіді слід описати причину невдачі. Якщо ви віддаєте перевагу цього не робити, просто використовуйте 404.