Il existe plusieurs façons de répondre à cette question:
Agrégation de points de terminaison
Les passerelles API regroupent principalement d'autres points de terminaison, pas nécessairement leurs résultats. Autrement dit, il s'agit d'un serveur unique qui pourrait refléter d'autres points de terminaison avec des fonctionnalités supplémentaires, telles que l'authentification ou le routage.
Le but est de centraliser certains services, de cacher les serveurs réels du réseau extérieur, etc.
Agrégation des résultats
Si vous voulez vraiment avoir une logique métier sur la passerelle, rassembler différents documents dans un autre document, ou simplement modifier des demandes ou des réponses, vous cherchez peut-être un bus de service d'entreprise .
Si l'agrégation est bonne
Ceci est bien sûr discutable et dépend des opinions individuelles. On pourrait faire valoir qu'il y a une raison pour laquelle nous nous sommes (principalement) éloignés des solutions de type SOA / ESB. Cette raison pourrait être due au fait que les responsabilités individuelles n'étaient pas claires et auraient tendance à s'accumuler du côté des ESB, laissant les points d'extrémité "muets". Finalement, l'ESB sait tout.
L'approche "REST" est différente. Il s'appuie sur des points de terminaison «intelligents», connaissant leur rôle et s'assurant qu'aucun autre composant n'a besoin de connaître les détails. Cette idée en soi semble être en conflit avec le fait d'en savoir plus sur les réponses .
En effet, il existe certaines idées d'architecture, comme les systèmes autonomes , qui s'appuient sur l'idée que toute fonction dont votre client aurait besoin devrait être entièrement couverte par un point de terminaison donné. Il ne devrait pas avoir besoin d'une communication synchrone avec les autres pour répondre à une demande dans son propre domaine de responsabilité. Cela suggère également que l'agrégation des résultats pourrait être contre-productive.
Comme toujours, tout dépend des exigences exactes.
