nommant des conseils

Question

hiérarchie Je suis en train de construire un service de repos qui a une large couverture de données de données sportives (résultats/équipement/équipes/joueurs/ligues, etc.) et les statistiques associées.

Venir avec une hiérarchie URI appropriée m'a faire le tour au moment en rond. Par exemple, je pourrais mettre en œuvre ...

1) i) version/sport/ligue/saison/entité

1) ii) Version/entité/sport/ligue/saison

1) iii) Version/sport/entité/ligue/saison

Un exemple rend les choses un peu plus clair (je l'espère) ...

Prenez une requête qui est de retourner tous les joueurs de football qui jouent dans la Premier League la saison 2010/2011 ...

2) i) 1.1/football/premier_league/2010_2011 fr/joueurs

2) ii) a) 1.1/joueurs/Football // premier_league/ 2010_2011 fr

Mais pas tous (sports les courses de chevaux - cheval et jockey, F1 etc.) ont vraiment des joueurs, alors les joueurs devraient-ils venir après le sport?

2) ii) b) 1.1/chevaux/horse_racing/gold_cup/2010

2) iii) a) 1,1/foot/joueurs/premier_league/2010_2011

2) iii) b) 1.1/horse_racing/chevaux/gold_cup/2010

Plus exemple ci-dessous ... URIs

1.1/joueurs/Football/premier_league/2010_2011/équipes/{id}
joueurs retours en équipe pour la saison?

1.1/joueurs/Football/premier_league joueurs retours dans la ligue de premier plan?

1.1/résultats/football/premier_league/2010_2011/équipes/{id} renvoie les résultats de la saison de l'équipe?

aussi j'envisage des requêtes telles que ...

1.1/Football/premier_league/2010_2011 fr/Novembre/équipes/{id}/Résultats

avec le mois agissant en tant que paramètre pour limiter le résultat ensemble.

Si le service devait inclure des entités non sportives, dites élections politiques ... il n'y aurait pas de joueurs ...

1.1/élections/2012/partis/{id}/résultats
renvoie les résultats pour le parti politique

1.1/élections/2012/partis/{id}/candidats renvoie les candidats associé à la partie

ou 1.1/résultats/élections/2012/partis/{id} renvoie les résultats pour le parti politique

1.1/candidats/élections/2012/partis/{id} renvoie les candidats associés à la partie

Tous les conseils sur la hiérarchie qui est mieux? J'ai essayé de rechercher ce site et google, mais les exemples que j'ai trouvés n'ont couvert que des cas triviaux. Je pense que je préfère l'exemple 2-iii.

Merci d'avance.

Answer 1

Mon conseil serait de créer des identifiants pour vos entités qui contiennent le minimum d'informations requises. par exemple.

/sport/{unqiueId} 
/player/{unqiueId} 
/horse/{unqiueId} 
/team/{unqiueId} 
/league/{unqiueId} 
/season/{unqiueId} 
/result/{unqiueId} 

Notez que j'ai supprimé la version de l'URL car je suis fermement dans le camp et je crois que les versions n'appartiennent pas aux URL.

Les relations un-à-un peuvent être gérées en intégrant des liens à des entités dans la réponse: par ex.

GET /player/234 
=> 
<Player Name="Kenny Dalglish"> 
    <Link rel="team" href="/team/732"/> 
</Player> 

Les relations un-à-plusieurs peuvent être traitées de manière similaire, mais cela nécessite de créer une sous-ressource de la ressource d'entité.

GET /team/732 
=> 
<team Name="Liverpool FC"> 
    <Link rel="players" href="/team/732/players"/> 
</Player> 

Habituellement, vous trouverez toutes sortes de scénarios où ce modèle est utile:

/league/{unqiueId}/teams 
/league/{unqiueId}/players 
/season/{unqiueId}/teams 
/league/{unqiueId}/seasons 
/player/{unqiueId}/teams 
/sport/{unqiueId}/teams 
/sport/{unqiueId}/leagues 
/sport/{unqiueId}/seasons 

Pour des représentations qui ne contiennent que des sous-ensembles de données, mais sont des requêtes communes, ils peuvent facilement être créés à l'aide des chaînes de requête et intégrées dans les résultats:

GET /league/891 
=> 
<league Name="Premiership"> 
    <link rel="leaderboard" href="/league/891/teams?startposition=1&endposition=10"/> 
    <link rel="currentseason" href="/season/972"/> 
    <link rel="lastseason" href="/season/842"/> 
    <link rel="sport" href="/sport/1"/> 
    <link rel="teams" href="/teams?league=891/> 
</league> 

une des caractéristiques intéressantes de ce type de « api » est qu'au lieu de construire une charge ensemble de règles dans votre application client Sur la façon de construire la structure de l'url pour faire une requête, l'application cliente adopte une approche différente. Le client doit connaître l'URL de départ et la signification des valeurs de l'attribut rel. De là, le client peut simplement naviguer pour obtenir ce qu'il veut. par exemple.

au lieu du client la construction d'une demande fondée sur la connaissance hardcoded de la hiérarchie du serveur qui ressemble à:

GET /Sport/Football/League/Premiership/Season/2011/Teams 

à la place qu'il navigue sur son chemin vers le résultat comme celui-ci:

GET/
=> 
<SportData> 
    <Link rel="sport football" href="/sport/1"/> <!-- Client finds this link --> 
    <Link rel="sport horseracing" href="/sport/2"/> 
    ... 
</SportData> 

GET /sport/1 
=> 
<Sport Name="Football"> 
    <Link rel="league premiership" href="/league/891"/> <!-- Client finds this link --> 
    ... 
</Sport> 

GET /league/891 
=> 
<League Name="Premiership"> 
    <Link rel="season 2011" href="/season/2334"/> <!-- Client finds this link --> 
    ... 
</League> 


GET /season/2334 
=> 
<Season Name="2011"> 
    <Link rel="teams" href="/season/2334/teams"/> <!-- Client finds this link --> 
    ... 
</Season> 

Je me rends compte que cela semble être beaucoup plus de travail que la première option, mais ce n'est pas aussi grave que ça en a l'air. L'utilisation de la mise en cache et des signets permet de réduire considérablement les allers-retours.Le principal avantage est que vous pouvez facilement modifier les ressources exposées par le service et introduire de nouvelles relations entre les ressources sans aucun effet sur le client.

Idéalement, dans un système basé sur REST, le seul couplage entre le client et le serveur est l'URL racine et les types de média qui sont renvoyés. Le client ne doit rien savoir de l'espace URL du serveur.