Предупреждения в REST API как некритические ошибки

9

У меня есть REST API, который для некоторых из таких объектов, как DELETE, POST или PUT, у меня есть некоторые правила проверки, которые могут возвращать ошибку.

Теперь мне нужен новый тип ошибки, такой как некритическая ошибка, которая должна завершаться с ошибкой обычным способом, но должна действовать, если есть отправка флагов «supress warnings». Такого пользователя могут спросить: «Вы действительно хотите изменить этот статус, вы еще не закончили»

Вопрос : есть ли лучшая практика для таких ошибок?

Дополнительные вопросы :

  • Есть ли какая-то семантика HTTP для такого поведения, которое я могу использовать?
  • я все еще придерживаюсь идеи REST (для меня это выглядит, я делаю) - я держу это без сохранения состояния
rest api user237329
источник
Как вы решаете, показывать ли пользователю такое предупреждение? Вы вызываете конечную точку API для проверки состояния приложения и затем предоставляете пользователю такой диалог, блокируя пользовательский интерфейс до тех пор, пока пользователь не ответит. Затем вы делаете фактический звонок. Вы также должны смоделировать это с помощью REST API: добавьте конечную точку, чтобы проверить, сохраняется ли она для выполнения определенных задач. Таким образом, любой пользователь API может выполнять проверки перед полетом и даже делегировать решение пользователю. Ваш подход с использованием кода состояния HTTP подобен операции, rm /fileкоторая «предупреждает», что файл доступен только для чтения, и в любом случае удаляется.
try-catch-finally
Это происходит, когда бизнес перекрывается с кодом состояния протокола. В любом случае. Вы пытались использовать свой собственный код статуса HTTP? Если Twitter может, вы тоже. Скажем, например 6xx? В любом случае, насколько я знаю, вы можете добавлять сообщения в тело ответа, даже если это 4xx (какой диапазон будет в вашем случае уместным).
Laiv
Наконец я использовал 409 CONFLICTдля предупреждения ответа. Таким образом, клиент получает указание, что он может принудительно вызвать вызов с той же конечной точкой и телом с параметрами exttra "force = 1"
user237329

Ответы:

4

В http нет кодов результата предупреждения, вы либо возвращаете успех (200), либо ошибку (400, 500). Единственное, что я знаю об этом, может быть аналогом того, что вы хотите, это что-то вроде кода 401 «несанкционированный» - что является явным отказом, но заставляет большинство клиентов автоматически повторять попытку подключения с учетными данными.

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

Таким образом, вы можете отправить флаг «Подавить предупреждения» вместе с вашим запросом, если он не установлен, сервер вернет код ошибки 409 (или аналогичный), а если установлен, вернет код 200 вместо этого. Пользователь не может спросить «хотите ли вы изменить этот статус» после отправки изменения статуса.

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

gbjbaanb
источник
Я ни в коем случае не говорю, что это правильно, но коды 3xx можно рассматривать как своего рода код уведомления или предупреждения, когда клиент может принять решение продолжить. Тем не менее, я бы предпочел либо выполнить действие, либо нет, и, возможно, я верну ответ с дополнительной информацией в возвращаемом теле или в заголовках.
Archimedix
0

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

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

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

TMN
источник
2
Мне никогда не нравились ответы, в которых говорилось: «Я успешно провалился» :-)
gbjbaanb