Правильний код статусу HTTP на неправильне введення

Що є оптимальним кодом відповіді HTTP, коли не повідомляється про 200 (усе гаразд), а помилка у введенні?

Мовляв, ви подаєте деякі дані на сервер, і він відповість, що ваші дані неправильні

використання 500схоже на тему сервера, що
використовується 200з текстом відповіді на попередження / помилку погано (дозволяє кешування, і все не в порядку),
використовуючи 204і повертаючи нічого, можливо, добре (але добре підтримується?)
використання 404неправильно, якщо запитуваний шлях (сценарій) доступний і в належному місці

У нас була така ж проблема і при створенні API. Ми шукали код статусу HTTP, еквівалентний an InvalidArgumentException. Ознайомившись із початковою статтею нижче, ми закінчили використовувати наступні 422 Unprocessable Entityстани:

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

джерело: https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm

Коди, що починаються з 4 (4xx), призначені для помилок клієнта. Може, 400 (поганий запит) може бути придатним до цієї справи? Визначення в http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html говорить:

"Сервер не міг зрозуміти запит через неправильний синтаксис. Клієнт НЕ повинен повторювати запит без змін."

На додаток до RFC Spec ви також можете бачити це в дії. Перевірте відповіді щебетання.

https://developer.twitter.com/en/docs/ads/general/guides/response-codes

409 Conflict може бути прийнятним рішенням.

Відповідно до: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Запит не вдалося виконати через конфлікт із поточним станом ресурсу. Цей код дозволений лише в тих випадках, коли очікується, що користувач зможе вирішити конфлікт і подати повторно запит. Орган реагування ДОЛЖЕН би включити достатньо інформації, щоб користувач міг розпізнати джерело конфлікту. В ідеалі суб'єкт відповіді повинен містити достатню кількість інформації для користувача або агента користувача, щоб вирішити проблему; однак це може бути неможливим і не потрібно.

Документ продовжує приклад:

Конфлікти, найімовірніше, виникають у відповідь на запит PUT. Наприклад, якщо використовувались версії та сутність PUT включала зміни до ресурсу, які суперечать тим, які були зроблені попереднім запитом (стороннім), сервер може використовувати відповідь 409, щоб вказати, що він не може виконати запит . У цьому випадку суб'єкт відповіді, ймовірно, містить список відмінностей між двома версіями у форматі, визначеному відповіддю Content-Type.

У моєму випадку я хотів би ввести рядок, який повинен бути унікальним, в базу даних через API. Перш ніж додати його до бази даних, я перевіряю, чи немає його ще в базі даних.

Якщо є, я повернусь "Error: The string is already in the database", 409.

Я вважаю, що цього хотіла ОП: код помилки, придатний, коли дані не відповідають критеріям сервера.

Відповідно до наведеного нижче сценарію,

Скажімо, хтось робить запит на ваш сервер із даними, які є у правильному форматі, але це просто не "хороші" дані. Так, наприклад, уявіть, що хтось розмістив значення String в кінцевій точці API, яка очікувала значення String; але, значення рядка містило дані, які потрапили у чорний список (наприклад, заборона людям використовувати "пароль" як свій пароль). тоді код статусу може бути або 400, або 422?

Досі я б повернув "400 поганих запитів", що, на думку w3.org, означає:

Сервер не міг зрозуміти запит через неправильний синтаксис. Клієнт НЕ повинен повторювати запит без змін.

Цей опис не зовсім відповідає обставині; але якщо ви переходите до списку основних кодів статусу HTTP, визначених протоколом HTTP / 1.1, це, мабуть, найкраща ставка.

Однак нещодавно хтось із моєї команди Dev вказав [мені], що популярні API починають використовувати розширення HTTP, щоб отримати більш детальну інформацію зі своїми повідомленнями про помилки. Зокрема, багато API, наприклад Twitter і Recurly, використовують код статусу "422 Unprocessable Entity", як визначено в розширенні HTTP для WebDAV. Код статусу 422 HTTP повідомляє:

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

Повернувшись до нашого прикладу паролів зверху, цей код статусу 422 вважається набагато доречнішим. Сервер розуміє, що ви намагаєтесь зробити; і він розуміє дані, які ви надсилаєте; він просто не дозволить обробляти ці дані.

404 - Не знайдено - може використовуватися для запиту URI, недійсний або ж запитуваний ресурс, такий як користувач, не існує.