Путаница с несколькими путями при разработке REST API - PullRequest
Новая
       16

Путаница с несколькими путями при разработке REST API

0 голосов
/ 29 мая 2019

У нас есть ресурсы с именем Игры и Игроки 

/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

Группирует запрос по тегу Games.Я использую Swagger API, поэтому этот вызов будет направлен на контроллер GamesAPI сгенерированного клиентом кода.Я считаю, что справедливо быть в API игр, а не в плеере, так как это связано с играми.

Проблема : выглядит слишком странным, чтобы рассматривать меня как особый идентификатор, как выглядитэто одна из форм {game-id}, которую я не могу переварить.

Сценарий 2 

/players/me/games -> Fetches games played by the current logged in player

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

Среди этих двух сценариев, который является лучшим способом решения этой проблемы

Ответы [ 3 ]

0 голосов
/ 29 мая 2019

Проектирование отношений основано на API, как спроектированы ваши схемы. Так что, в вашем случае

1 Игрок может играть в 1 или во многие игры - так что 1 до Множество отношение

Следовательно, вы должны группировать игровые данные по игрокам.Таким образом, возникает 2 сценария для повышения производительности API

Сценарий 1

Легче ли искать в играх идентификатор игрока, а затем группировать его?

Сценарий 2

Легче ли искать игроков по идентификатору игры, а затем группировать их?

Логически, говоря и учитывая сценарий 1, можно сделатьбольше смысла, следовательно 

/games/{player-id} -> Fetches games played by the current logged in player
0 голосов
/ 13 июня 2019

Вот как я это решил.

Как уже упоминалось в сценарии 1, я вижу, что "я" конфликтует с {game-id} и сбивает с толку пользователей.В сценарии 2 я вижу, что выборка пользовательских игр из API-интерфейса игрока не является интуитивно понятной.

Поэтому я выбрал подход, в котором он пытается сохранить конечные точки минимальными.Я добавил новый параметр запроса «playsOnly: boolean» для GET / games, который возвращает все игры, связанные с игроком.

Это упрощает многие вещи.Я все еще могу пойти с / конечной точки игры и больше не путать!

0 голосов
/ 29 мая 2019

Сценарий 1, кажется, лучше среди двух, потому что, как правило, URL ваших игр попадет в GameController, и там вы можете иметь функцию действия для извлечения всех игр, одной игры с заданным идентификатором или игр пользователя, вошедшего в систему.

...