Путаница с несколькими путями при разработке REST API
У нас есть ресурсы под названием «Игры и игроки».
/games -> Get all Games available
/games/{game-id} -> Get the game details of specific Game with game-id
/players/me -> Get logged in Player details
Будут игры, в которые играет игрок, которые можно пометить в разделе «Игры» или «Игроки».
Сценарий 1
/games/me -> Fetches games played by the current logged in player
Это группирует запрос под тегом «Игры». Я использую Swagger API, поэтому этот вызов будет направляться контроллеру GamesAPI в сгенерированном клиентом коде. Я считаю справедливым быть в API игр, а не в игроке, поскольку это связано с играми.
Проблема : Это выглядит слишком странно, чтобы рассматривать «я» как особый идентификатор, так как похоже, что это одна из форм {game-id}, которую я не могу переварить.
Сценарий 2
/players/me/games -> Fetches games played by the current logged in player
Это группирует его под тегом Player, который переходит в PlayerAPI после генерации кода. Путь имеет хорошее значение, но более уместно иметь его в GamesAPI (по моему выбору - я могу ошибаться, подскажите, пожалуйста)
Какой из этих двух сценариев является лучшим способом решения этой проблемы?
Ответы 3
Сценарий 1 кажется лучшим из двух, потому что, как правило, URL-адрес ваших игр попадает в GameController, и там вы можете иметь функцию действия для получения всех игр, одной игры с заданным идентификатором или игр пользователя, вошедшего в систему.
Дизайн отношений основан на API, как ваши схемы разработаны. Итак, в вашем случае
1 игрок может играть в 1 или несколько игр — отношение 1 ко многим
Следовательно, вы должны группировать игровые данные на основе игроков. Таким образом, возникает 2 сценария повышения производительности API.
Сценарий 1
Не проще ли искать в играх идентификатор игрока, а затем группировать их?
Сценарий 2
Не проще ли искать игроков по идентификатору игры, а затем группировать их?
Логически, говорить и рассматривать сценарий 1 имеет больше смысла, поэтому
/games/{player-id} -> Fetches games played by the current logged in player
@Ayyappa как дела?, это даст вам игру для идентификатора игрока, где `/games/{game-id}` дает вам игру для идентификатора игры
Это не так работает. {player-id} или {game-id} может быть любым идентификатором или буквенно-цифровым значением. Трудно классифицировать или сгруппировать все документы/записи в рамках одного ресурса только по идентификатору.
Вот как я это решил.
Как упоминалось в Сценарии 1, я вижу, что «я» конфликтует с {game-id} и смущает пользователей. В Сценарии 2 я вижу, что выбор пользовательских игр из API проигрывателя не интуитивно понятен.
Поэтому я выбрал подход, при котором он пытается свести конечные точки к минимуму. Я добавил новый параметр запроса "playedOnly:boolean" для GET /games, который возвращает все игры, связанные с игроком.
Это упрощает многое. Я все еще могу использовать конечную точку /games, и больше никакой путаницы!
/games/{player-id} -> но это конфликтует с GET /games/{game-id}