Est-ce une bonne idée de fusionner plusieurs requêtes HTTP pour économiser la bande passante?

Je prépare une application d'une seule page qui serait parfois utilisée sur une connexion mobile lente. Une partie de sa part est assez lourde en termes de requêtes API (extraire dix ressources différentes pour un nouvel affichage d'écran).

Maintenant, est-ce une bonne idée de fusionner ces services à un qui fournit toutes les données requises, mais qui n'est pas aussi "pur" en termes de principes REST? Y a-t-il des gains de performance importants à prévoir?

L'un des avantages de REST est la possibilité de mettre en cache les demandes via des caches http traditionnels (en supposant qu'il s'agit de demandes pouvant être mises en cache).

Lorsque vous avez des demandes uniques, plus grandes, moins fréquemment utilisées et éventuellement différentes (je vais récupérer des éléments a,b,c,dcette fois-ci et des éléments la a,b,d,eprochaine fois), vous avez plus de chances que la demande soit un échec de cache et expire à partir d'un cache qui peut être assis quelque part entre vous et la source.

Étant donné les deux ensembles de demandes mentionnés ci-dessus, la deuxième demande peut avoir un taux de réussite du cache de 75% et être beaucoup plus rapide à récupérer e, plutôt que les quatre choses.

Notez que cela peut ne pas être immédiatement apparent pour les personnes qui l'utilisent, car la personne qui effectue le premier ensemble de demandes de cache manquera toujours le cache manquera.

Cela ne veut pas dire qu'il serait idéal sur une connexion réseau mobile où l'on est moins susceptible d'obtenir des accès de cache non locaux. Mais pour les points chauds ou d'autres situations wifi, les accès au cache pourraient être beaucoup plus utiles.

Encore une fois, cela dépend en grande partie du fonctionnement de votre application. Demande-t-il toutes ces données au démarrage? ou parlons-nous d'un chargement de page où les attentes de temps de réponse sont différentes?

L'idéal serait de tester ceci pour voir comment votre application se forme dans une variété de situations. Envisagez de configurer une situation où vous avez lié votre appareil mobile à un réseau wifi local que vous pouvez surveiller (ce n'est que le premier coup sur google) et simuler une mauvaise connexion Internet pour voir comment les choses fonctionnent réellement (ou pas) et lequel a les meilleures performances.

Votre intuition est quelque peu correcte - dans l'ensemble, faire moins de demandes est certainement préférable; les API volumineuses ont tendance à être meilleures. Surtout avec une connectivité inégale où vous pouvez voir du travail et d'autres échouer à créer des scénarios de repli cauchemardesques car rien ne peut compter sur quoi que ce soit.

Il y a une grande mise en garde - vous pouvez devenir beaucoup trop gros et vos appels et réponses deviennent gonflés. Par exemple, il peut être judicieux d'avoir un gros appel lorsque vous accédez à une page pour la première fois, puis que les mises à jour soient diffusées en petites bouchées plutôt que de forcer une actualisation de la grande page chaque fois que vous voulez des données.

Ou, vous voudrez probablement le faire dans les deux sens.

Check-out cet article du blog Dropbox Tech .

Ils y décrivent en détail pourquoi et comment ils ont mis en œuvre exactement la solution que vous avez proposée pour récupérer les vignettes de toutes vos photos. Il faut dire qu'ils mesurent les performances pour voir si cela en vaut la peine, et apparemment c'est le cas.

Court résumé:

Le site Web Dropbox doit charger des centaines de vignettes. En raison des limitations de certains navigateurs, toutes les miniatures ne sont pas chargées en parallèle (les demandes sont mises en file d'attente). Ils voulaient utiliser SPDY , mais n'ont pas pu le faire car certaines parties de leur système ne le prennent pas encore en charge. Au final, ils ont utilisé des requêtes par lots sur HTTP, qui renvoient plusieurs miniatures par réponse sous forme compressée. L'amélioration globale du temps de chargement des pages était de 40% selon leurs résultats.

En bref: votre approche est quelque peu correcte et pourrait bénéficier d'un service wrapper.

Ce service combinera les appels uniques existants en une seule méthode côté service. Pour ce faire, en combinant les appels du client vers le service et en utilisant tous les appels uniques, atomiques et reposants que vous avez probablement déjà mis en place.

Ainsi, vous continuerez à bénéficier de REST en tant que possibilité de mettre en cache les demandes.

Cependant, au final, tout se résumera aux performances de l'infrastructure de service / serveur et à l'environnement client qui devraient le consommer.