Ci sono molti modi in cui questa domanda può essere risolta:
Aggregazione di endpoint
I gateway API per lo più aggregano 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 attuali dalla rete esterna, ecc.
Aggregazione dei risultati
Se vuoi davvero avere una logica di business sul Gateway, estraendo documenti diversi in un altro documento, o semplicemente alterando richieste o risposte, potresti guardare un Enterprise Service Bus .
Se l'aggregazione è buona
Questo è ovviamente discutibile, e fino a opinioni individuali. Si potrebbe obiettare che esiste una ragione per cui ci siamo allontanati (soprattutto) dalle soluzioni di tipo SOA / ESB. Questo potrebbe essere dovuto al fatto che le responsabilità individuali non erano chiare e tendevano a raccogliere sul lato ESB, lasciando gli endpoint "stupidi". Alla fine risultante in ESB sapendo tutto.
L'approccio "REST" è diverso. Si basa su endpoint "intelligenti", conoscendo la loro parte e assicurandosi che nessun altro componente abbia bisogno di conoscere alcun dettaglio. Questa idea in sé sembra essere in conflitto con il fatto che il Gateway sappia di più sulle risposte .
In effetti, ci sono alcune idee di architettura, come Sistemi autonomi , che si basano sull'idea, che qualsiasi funzione il tuo cliente dovrebbe essere coperto completamente da un dato endpoint. non dovrebbe avere bisogno di 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.