Diese Frage kann auf verschiedene Arten beantwortet werden:
Aggregation von Endpunkten
API-Gateways aggregieren meist andere Endpunkte, nicht unbedingt deren Ergebnisse. Das heißt, es handelt sich um einen einzelnen Server, der möglicherweise andere Endpunkte mit zusätzlichen Funktionen wie Authentifizierung oder Routing spiegelt.
Es geht darum, einige Dienste zu zentralisieren, die eigentlichen Server vor dem externen Netzwerk zu verstecken usw.
Zusammenfassung der Ergebnisse
Wenn Sie wirklich Geschäftslogik auf dem Gateway haben möchten, verschiedene Dokumente zu einem anderen Dokument zusammenführen oder einfach nur Anforderungen oder Antworten ändern möchten, sollten Sie sich einen Enterprise Service Bus ansehen .
Ob die Aggregation gut ist
Dies ist natürlich umstritten und hängt von den individuellen Meinungen ab. Man könnte argumentieren, dass es einen Grund gibt, warum wir uns (größtenteils) von SOA / ESB-Lösungen verabschiedet haben. Dies könnte daran liegen, dass die individuellen Verantwortlichkeiten unklar waren und sich tendenziell auf der ESB-Seite ansammelten und die Endpunkte "dumm" blieben. Letztendlich weiß der ESB alles.
Der "REST" -Ansatz ist anders. Es baut auf "intelligenten" Endpunkten auf, kennt deren Teil und stellt sicher, dass keine anderen Komponenten die Details kennen müssen. Diese Idee an sich scheint im Widerspruch dazu zu stehen, dass das Gateway mehr über die Antworten weiß .
In der Tat gibt es einige Architekturideen wie in sich geschlossene Systeme , die auf der Idee aufbauen, dass jede Funktion, die Ihr Client benötigen würde , vollständig von einem bestimmten Endpunkt abgedeckt werden sollte . Sie sollte keine synchrone Kommunikation mit anderen benötigen, um eine Anforderung in ihrem eigenen Verantwortungsbereich zu erfüllen. Dies lässt auch darauf schließen, dass die Aggregation von Ergebnissen kontraproduktiv sein könnte.
Wie immer kommt es auf die genauen Anforderungen an.
