Попередження в API REST як не критичні помилки

9

У мене є API REST, що для деяких даних, таких як DELETE, POST або PUT, у мене є деякі правила перевірки, які можуть повернути помилку.

Тепер мені потрібен новий тип помилки, як некритична помилка, що вона повинна вийти з ладу нормальним способом, але повинна піти на дію, якщо буде надіслано прапорців "подавлення попередження". Такого користувача можна запитати: "Ви впевнені, що хочете змінити цей статус, ви ще не закінчили"

Запитання : чи є найкраща практика щодо подібних помилок?

Вторинні питання :

Чи є якісь HTTP семантичні для такої поведінки, які я можу користуватися користувачем?
чи досі я дотримуюся ідеї REST (для мене це виглядає, як я це роблю) - я тримаю її без громадянства

rest api

— user237329
джерело

Як ви вирішите, чи потрібно показувати таке попередження користувачеві? Ви викликаєте кінцеву точку API, щоб перевірити стан програми, а потім представити користувачеві таке діалогове вікно, блокуючи інтерфейс користувача, поки користувач не відповість. Тоді ви здійснюєте фактичний дзвінок. Ви також повинні моделювати це з вами API REST: додайте кінцеву точку, щоб перевірити, чи збережено виконувати певні завдання. Таким чином, будь-який користувач API може робити перевірки перед польотом і навіть делегувати рішення користувачеві. Ваш підхід до коду HTTP-статусу - це такий, rm /fileщо "попереджає", що файл читається лише в той же час, видаляючи його.

— пробуй-нарешті

Це відбувається, коли бізнес перекривається кодом статусу протоколу. Все одно. Чи намагалися ви використовувати власний код статусу HTTP? Якщо Twitter може, і ви. Скажімо, наприклад, 6xx? Досі, наскільки я знаю, ви можете додавати повідомлення в тіло відповідей, навіть якщо це 4хx (який діапазон буде апропійований у вашому випадку).

— Лаїв

Нарешті, я використовував 409 CONFLICTдля реагування на попередження. Таким чином, клієнту доручають, що він може змусити виклик з тією ж кінцевою точкою та тілом з параметрами exttra "force = 1"

— user237329

4

У http немає кодів попередження про попередження, ви повертаєте успіх (200) або помилку (400, 500). Єдине, що мені відомо, що може бути аналогічним тому, що ви хочете, - це щось на зразок коду 401 «несанкціонований» - це відвертий збій, але змушує більшість клієнтів автоматично повторно намагатися зв’язатися з обліковими записами.

Для API REST вам потрібно повідомити серверу про стан запиту і як обробити результат - ви не можете надіслати PUT і очікувати помилки, якщо клієнт не закінчений, або успіх, якщо він є - сервер повинен це знати інформацію, щоб повернути правильний код результату.

Таким чином, ви можете надіслати прапор "придушити попередження" зі своїм запитом, якщо він не встановлений, сервер повертає код помилки 409 (або подібний), а якщо встановлено, повертає код 200 замість цього. Користувача не можна запитати "чи бажаєте ви змінити цей статус" після надсилання зміни статусу.

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

— gbjbaanb
джерело

Я жодним чином не кажу, що це правильно робити, але коди 3xx можна розглядати як якесь повідомлення або код попередження, коли клієнт може вирішити продовжити. З цього приводу я скоріше або виконую дію, або не роблю, і, можливо, повертаю відповідь з додатковою інформацією у поверненому тілі або в заголовках.

— Архімедікс

0

Якщо ви хочете дозволити користувачеві змінювати ваше нормальне поводження з помилками, ви можете розглянути можливість повернення 200 SUCCESS статусу з додатковою інформацією в розширених заголовках HTTP. Наприклад, ви могли повернутися

X-APP-STATUS: 422 Unprocessable entity
X-APP-SOURCE: Invalid ID 'fo0'

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

— TMN
джерело

2

Мені ніколи не сподобалися відповіді, які говорять "я успішно провалився" :-)

— gbjbaanb