Чи слід використовувати коди статусу HTTP для представлення помилок ділової логіки на сервері?

Я перебуваю на перехресті з деяким дизайном API для клієнта (JS у браузері), щоб поговорити з сервером. Ми використовуємо HTTP 409 Conflict для представлення невдалої дії через дію запобіжного блокування. Замок satefy запобігає випадковим внесенням змін у виробничі системи наших клієнтів. Мені було доручено попрацювати з 409s трохи більш витончено клієнтом, щоб вказати, чому конкретний виклик API не вдався.

Моє рішення полягало в тому, щоб перекрити обробники відмов будь-якого з наших дзвінків AJAX, які відображатимуть сповіщення про клієнта, коли щось виходить з ладу через 409 - це все нормально і добре працює поряд з іншими помилками 4XX і 5XX, які використовують той самий механізм.

Виникла проблема, коли один із наших обробників маршрутів відповідав на 409s, коли виникає помилка ділової логіки - моя обгортка AJAX повідомляє, що запобіжник увімкнено, тоді як існуючий обробник несправності клієнта повідомляє, що (на його думку) проблема базується на тілі відповіді. Простим рішенням було б змінити відповідь обробника або код статусу, який ми використовуємо для представлення блокування безпеки.

Що приводить мене до мого перехрестя: чи повинні коди статусу HTTP навіть використовуватися для представлення помилок ділової логіки? Це питання стосується тієї ж проблеми, з якою я стикаюся, але вона не отримала особливої ​​тяги. Як запропоновано у пов'язаній відповіді, я схиляюся до використання HTTP 200 OK з відповідним органом, щоб представити збій у діловій логіці.

У когось є якісь переконання? Хтось може переконати мене, що це неправильний спосіб представити невдачу?

Кейсі висвітлює основну точку.

Ключова ідея будь-якої веб-програми: ви адаптуєте свій домен так, щоб він виглядав як магазин документів. GET / PUT / POST / DELETE тощо - це всі способи взаємодії зі сховищем документів.

Так в способі мислення про те , що коди використання, щоб зрозуміти , що аналогічна операція в документі магазині, і що ця невдача буде виглядати в цьому аналогу.

2xx абсолютно непридатний

2xx (Успішний) клас коду статусу вказує на те, що запит клієнта був успішно отриманий, зрозумілий та прийнятий.

5xx також непридатний

Клас коду статусу 5xx (помилка сервера) вказує на те, що сервер знає, що він помилився

У цьому випадку сервер не помилився; відомо про те, що наразі вам не слід змінювати цей ресурс.

Помилки бізнес-логіки (мається на увазі, що інваріант бізнесу не дозволяє запропонувати редагувати наразі), ймовірно, 409

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

Зверніть увагу на цей останній шматочок - корисне навантаження відповіді 409 повинно повідомляти споживачеві інформацію про те, що пішло не так, і в ідеалі включає в себе контроль гіпермедіа, який приводить споживача до ресурсів, які можуть допомогти вирішити конфлікт.

Моє рішення полягало в тому, щоб перекрити обробники відмов будь-якого з наших дзвінків AJAX, які відображатимуть сповіщення про клієнта, коли щось виходить з ладу через 409 - це все нормально і добре працює поряд з іншими помилками 4XX і 5XX, які використовують той самий механізм.

І я зазначив би це як проблему; Ваша реалізація у клієнта припускала, що код статусу є достатнім для визначення проблеми. Натомість ваш клієнтський код повинен переглядати корисне навантаження та діяти на наявній там інформації.

Тобто, зрештою, як це зробив би магазин документів

409  Conflict

your proposed change has been declined because ${REASON}.  
The following resolution protocols are available: ${LINKS[@]})

Той самий підхід з a 400 Bad Requestтакож був би прийнятний; що приблизно "перекладається на" Виникла проблема з вашим запитом. Нам не шкода зрозуміти, який код статусу найкраще підходить, тож ось вам. Детальні відомості див. У корисному навантаженні ".

Я б використовував 422. Введення дійсне, тому 400 не є правильним кодом помилки для використання

Специфікація WebDAV включає цю рекомендацію

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

Я не вірю, що це цілком збіг (хоча я згоден, що це викликає певні сумніви 400як альтернативу). Моя інтерпретація полягає в тому, що 422означає "ви надіслали неправильну сутність", де 409"ви надіслали організацію в неправильний час".

По-іншому, 422вказує на проблему з повідомленням запиту, розглянутим ізольовано, де 409вказується, що повідомлення запиту суперечить поточному стану ресурсу.

Дискусія Бен Надала про 422 може бути корисною для розгляду.

На мій досвід, коди помилок HTTP недостатньо для представлення бізнес-помилок. Однак вони корисні для представлення класів помилок.

Отже, моя рекомендація полягатиме в тому, щоб використовувати коди помилок HTTP для категорій помилок, але вибирати конкретну помилку для відмов ділової логіки (наприклад, 409 Конфлікт ... 200 ОК буде вводити в оману) і включати дані у відповідь із зазначенням конкретної бізнес-помилки . Переконайтеся, що це частина вмісту відповіді, а не текст статусу, оскільки деякі веб-переглядачі ігнорують спеціальний текст статусу. Мова, яку я люблю використовувати, має типи Union, які зручні для представлення повідомлень. Але ви також можете визначити рядкові константи для випадків помилок.

Приклади

// error with text response
409 Conflict "safety_lock_engaged"
409 Conflict "customer_not_eligible_for_selected_discount"
// warning with JSON response
202 Accepted { "backorderedProductIds": [ 37, 476 ] }

Як правило, я б уникав використання кодів HTTP-статусу для представлення конкретних помилок ділової логіки. Це тому, що вони вже мають смислове значення, яке визначається світовим стандартом. Інші системи, нові диски та інше будуть заплутані вашим відхиленням від стандарту.

Я знайшов у останніх подібних дослідженнях те, що його прийнято використовувати 400 Bad Requestу випадку помилок перевірки і подібних. Таким чином, ви використовуєте один код статусу для всіх помилок бізнес-логіки.

Між іншим, його 409слід використовувати, коли ресурс змінився під час редагування та спробу зберегти його знову.

Ви можете скористатися "Поганим запитом" та включити ідентифікатор порушеного бізнес-правила плюс додаткові деталі на тілі відповіді.