Esistono diversi modi a cui è possibile rispondere a questa domanda:
Aggregazione di endpoint
I gateway API aggregano principalmente altri endpoint, non necessariamente i loro risultati. Cioè, è un singolo server che potrebbe rispecchiare altri endpoint con alcune funzionalità aggiuntive, come l'autenticazione o il routing.
Il punto è centralizzare alcuni servizi, nascondere i server effettivi dalla rete esterna, ecc.
Aggregazione dei risultati
Se vuoi davvero avere una logica di business sul Gateway, riunire documenti diversi in un altro documento o semplicemente modificare richieste o risposte, potresti guardare un bus di servizio aziendale .
Se l'aggregazione è buona
Questo è ovviamente discutibile, e fino alle opinioni individuali. Si potrebbe obiettare che c'è una ragione per cui ci siamo allontanati (principalmente) dalle soluzioni di tipo SOA / ESB. Questo motivo potrebbe essere dovuto al fatto che le responsabilità individuali non erano chiare e tendevano a raccogliere dal lato ESB, lasciando gli endpoint "stupidi". Alla fine risulta che l'ESB sa tutto.
L'approccio "REST" è diverso. Si basa su endpoint "intelligenti", conoscendo la loro parte e assicurandosi che nessun altro componente debba conoscere alcun dettaglio. Questa idea in sé sembra essere in conflitto con il far conoscere al Gateway di più sulle risposte .
In effetti, ci sono alcune idee di architettura, come i sistemi autonomi , che si basano sull'idea che qualsiasi funzione di cui il tuo cliente avrebbe bisogno dovrebbe essere completamente coperta da un determinato endpoint. Non dovrebbe essere necessaria una comunicazione sincrona con gli altri per soddisfare una richiesta nella propria area di responsabilità. Ciò suggerisce anche che l'aggregazione dei risultati potrebbe essere controproducente.
Come sempre, tutto dipende dai requisiti esatti.