Дилемма между 2xx и 4xx кодами состояния в api rest - PullRequest
0 голосов
/ 12 января 2019

Я думаю, что эта проблема не тривиальна, поэтому я хотел бы выразить это подробно

Домен:

У меня есть конечная точка (api rest), которая получает дату и время встречи, которую я хочу заблокировать (которая позже будет зарезервирована). Операция проста: при получении даты и времени она блокируется, так что другой клиент не может записаться на встречу в тот же день и время, а тот, который блокирует встречу, заполняет контактную информацию.

Пока все очень просто. Проблема начинается, когда два разных пользователя выбирают одну и ту же дату и время в своем браузере, и два запроса запускаются одновременно. Как мы уже знаем, вы не можете заблокировать встречу в один и тот же день и время дважды, поэтому приложение не будет работать (хотя этот сбой должным образом контролируется).

Короче говоря, два пользователя пытаются заблокировать встречу в одну и ту же дату и время, и только запрос, обработанный первым, будет успешным. Для пользователя, которому удалось заблокировать встречу, ответ ясен: 200 OK статус. Вопрос в том, какой код состояния http соответствует возвращению второму пользователю?

Комментарий:

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

  • 2xx: Половина людей ответили, что код штата должен быть 2xx. Зачем? во-первых, потому что запрос хорошо сформулирован (в основном параметры написаны правильно), поэтому он не будет соответствовать клиентской ошибке (4xx), а с другой стороны, это не является неожиданной ошибкой сервера (500), так как он должным образом контролируется самой бизнес-логикой. Так как запрос был выполнен правильно, он должен отправить статус 2xx (точнее 200), указывающий, что запрос был успешным, с сообщением в теле, указывающим «статус» действия (назначение не может быть заблокировано).
  • 4xx: Моя позиция (а также позиция остальных 50% опрошенных) заключается в том, что, как видно, запрос не выполняется, поскольку желаемое действие не может быть выполнено. Совсем не кажется логичным, что возвращается 200 OK (что говорит о том, что все прошло хорошо) и сообщение, описывающее возникшую ошибку или состояние (в некотором смысле, это будет противоречить мне). При возникновении ошибки виновно только 2: клиент и сервер. В этом случае мне кажется, что сервер не является таковым, потому что он не выходит из строя неожиданно, но это бизнес-правило хорошо продумано и намеренно терпит неудачу (так что это не будет 5xx). Кажется, все вписывается в то, что это ошибка клиента, возможно, семантическая ошибка при попытке выполнить одну и ту же операцию дважды на одном и том же ресурсе. Поэтому, по моему мнению, ошибка 400 приспособилась бы к ситуации, и, возможно, если мы хотим быть более точной, 409, что указывает на то, что мы пытались одновременно изменить ресурс, который не позволяет это действие.

Какой должна быть соответствующая опция для этого случая?

Спасибо!

1 Ответ

0 голосов
/ 12 января 2019

Давайте посмотрим, что может предложить Википедия и MDN по этому вопросу:

2xx (успешно): запрос был успешно получен, понят и принят

4xx (ошибка клиента): запрос содержит неверный синтаксис или не может быть выполнен

(источник: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes)

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

Ситуация квалифицируется как 4xx, либо когда запрос содержит неверный синтаксис (что здесь не так, поскольку запрос корректно сформирован), или когда запрос не может быть выполнен (что, по-видимому, является случаем, который вам нужен общаться с клиентом). Можно предложить использовать 422 для ошибок такого рода, которые характерны для случая использования в бизнесе (например, планировщик встреч для вашего случая)

Согласно MDN:

Код состояния ответа непроцессируемого объекта по протоколу гипертекста (HTTP) 422 указывает, что сервер понимает тип содержимого объекта запроса, и синтаксис объекта запроса является правильным , но это было невозможно обработать содержащиеся в нем инструкции.

(источник: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422)

Кроме того, поскольку при бронировании встречи будет создан ресурс в бэк-энде (т. Е. Действительный идентификатор встречи с информацией о посетителе, времени и т. Д.), Я бы предпочел отправить обратно код состояния 201 (Создан) для успеха. случай, когда вы выполняете задачу синхронно. На мой взгляд, код состояния 200 (ОК) больше подходит для ситуаций, когда ресурс создается асинхронно, и может быть недоступен сразу, когда сервер ответит клиенту. В таких случаях мы обычно предоставляем ссылку на запрос GET, откуда клиент может получить запрошенный ресурс в будущем.

...