Должен ли я использовать один HTTP-запрос, чтобы проверить, возможно ли действие, затем другой, чтобы выполнить это действие, или я должен объединить его в один запрос?

Question

Я создаю веб-сайт, где пользователи могут присоединиться к игровым комнатам до определенного количества игроков. Я не уверен, как мне следует обращаться с пользователем, пытающимся войти в комнату. Я подумал о двух идеях:

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

Второй подход кажется более эффективным, с меньшим количеством возвратов вперед и назад между внешним интерфейсом и внутренним интерфейсом, но он также создает несогласованность в формате ответа. Что лучше?
Если это уместно, я использую стек MERN с REST API, но я думаю, что мой вопрос носит более общий характер.

Answer 1

Важно отметить, что вы находитесь в распределенной системе - клиент не блокирует"комнату" от других изменений. Фактически это означает, что вы говорите о данных извне : информация, видимая веб-клиентом, устарела (устарела не менее наносекунд) и может быть изменена.

условие гонки - к моменту поступления запроса на добавление доступность комнаты может измениться.

Это означает, что ваш протокол для запроса на добавление требует некоторого обеспечения для не очень довольных -дорожка. И клиентская реализация должна будет обрабатывать случай, когда запрос на добавление дает желаемый ответ.

Так что каждый должен все равно обработать этот случай; предполетная проверка на самом деле не спасает вас от какой-либо работы.

Так что с вашим вторым подходом все в порядке.

, но это также создает несогласованность в формате ответа.

Не совсем - опять же, вы должны обработать режимы отказа. Так что теперь мы просто спорим о том, какие данные / метаданные используются в качестве предиката, где должен распространяться код клиента.

Answer 2

Я думаю, что лучшим выбором будет go с вариантом # 2. Нет необходимости делать два запроса, если комната не заполнена. Вам просто нужно определить наиболее подходящий ответ, если комната заполнена. Вы можете либо вернуть 200 (ОК), и с некоторым значимым кодом ошибки в теле ответа, который, как знает ваш клиент, означает, что комната заполнена; или go с кодом уровня 500, например, 503 (Сервис недоступен), чтобы указать, что комната не может быть присоединена. Поскольку заполненная комната не является «ошибкой», связанной с клиентом, код уровня 400 не подходит.