Nous développons une API REST qui, entre autres, sera consommée par un frontend HTML5 via javascript. L'application est destinée à être utilisée au sein de l'organisation et compte généralement environ 300 utilisateurs, mais nous voulons bien évoluer jusqu'à 1 000 utilisateurs environ.
Normalement, les connexions à l'API seront établies dans le LAN afin que la qualité et la latence de la connexion soient bonnes, bien qu'il ne soit pas exclu une utilisation occasionnelle sur Internet où les connexions pourraient être plus lentes et avec plus de retard via 3G / 4G.
Les deux options que nous pensions sont:
Le frontend fera plusieurs appels asynchrones simultanés à l'API pour charger les différents composants de l'interface.
- Avantages: simplicité.
- Inconvénients: Plus de connexions au serveur.
Le contrôleur du frontend fera un seul appel à l'API en passant comme paramètres quels objets doivent être récupérés.
- Avantages: une seule connexion au serveur, bien que le serveur établisse plusieurs connexions à la base de données.
- Inconvénients: nécessite des mécanismes à la fois frontend et API. Cela complique le design.
Explications supplémentaires: Il y aura différentes ressources ... / Produit ... / Emplacements, etc. Ces ressources pourraient être récupérées seules, mais il y aura une autre ressource abstraite ... / écran? Produit et emplacements qui extraira les deux en un seul appel.
/screen?Product&Locations
est une mauvaise approche, au moins avec toute l'expérience que j'ai en développant des API REST et une application web qui les a utilisées. D'un point de vue purement monolithique (par exemple dans Ruby on Rails), avoir un itinéraire/screen
qui charge les deuxProduct
et lesLocation
ressources est parfaitement bien. Cependant, du point de vue REST , vous ne voudrez jamais qu'un itinéraire en charge plus d'un (sauf si vous JOIGNEZ des tables pour obtenir plus de données à la fois). Que/screen
devrait faire est de charger une page de mise en page de base et vous AJAX votre API pour obtenir les données (Product
,Location
, etc.)./screen
AJAXHTTP GET
vers/products/popular
et/locations
). Votre API ne doit pas être celle qui effectue plusieurs chargements, car il est peu probable que vous affichiez les données de la même manière dans une application Web vs Android par exemple.