Nombreux appels asynchrones vs appel unique à l'API

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:

1. 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.

2. 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.

L'option 1 (appels asynchrones multiples) est le meilleur choix car:

1. chaque appel individuel est sa propre entité , vous pouvez donc réessayer individuellement en cas d'échec. Dans l'architecture monolithique «à un appel», si une chose échoue, vous devez refaire tout l'appel
2. le code côté serveur sera plus simple: encore une fois, la modularité , ce qui signifie que différents développeurs peuvent travailler sur différentes ressources API
3. Dans un modèle MVC typique, il n'est pas logique qu'un seul appel API charge plusieurs ressources distinctes ; par exemple, si vous faites une demande pour /productsobtenir une liste de produits à afficher sur une page et que vous souhaitez également afficher une liste des emplacements où les produits populaires sont vendus, vous disposez de deux ressources distinctes: Productet Location. Bien qu'ils soient affichés sur la même page, vous ne pouvez pas logiquement appeler /productset le renvoyer également.
4. vos rapports de journalisation / utilisation seront plus simples dans l'approche modulaire. Si vous faites une demande à /productset que vous chargez également des emplacements, vos fichiers journaux vont être vraiment déroutants
5. si vous avez un problème avec une ressource particulière, l'approche d'un appel entraînera la rupture de la page entière et il ne sera pas évident pour vos utilisateurs ce qui s'est cassé - et cela signifie que votre équipe mettra plus de temps à résoudre le problème; cependant, dans l'approche modulaire, si une chose se casse, il sera très évident ce qui s'est cassé et vous pouvez le réparer plus rapidement. Cela ne ruinera pas non plus le reste de la page (à moins que les choses ne soient trop étroitement liées ...)
6. il sera plus facile de faire des changements en général si les choses sont séparées; si vous avez 5 ressources en cours de chargement par un seul appel API, il sera plus difficile de comprendre comment ne pas casser les choses lorsque vous voulez changer quelque chose

Le fait est que les ressources sont séparées, et dans une API REST, renvoyer de nombreuses ressources distinctes à partir d'un chemin d'API unique n'a aucun sens, même si vous "enregistrez des connexions au serveur". Soit dit en passant, l'utilisation de paramètres pour charger conditionnellement (différentes) ressources n'est pas RESTful.

Cela dit, la seule option logique est de faire plusieurs demandes asynchrones pour séparer les ressources: adoptez l'approche modulaire !

PS - N'optimisez pas prématurément les «connexions au serveur», en particulier lorsque les connexions HTTP sont incroyablement faibles et que vous êtes sur un réseau local. Ce genre de réflexion au lieu de choisir le design le plus simple dès le départ va vous causer des ennuis plus tard.