Na to pytanie można odpowiedzieć na wiele sposobów:
Agregacja punktów końcowych
Bramy API najczęściej agregują inne punkty końcowe, niekoniecznie ich wyniki. Oznacza to, że jest to pojedynczy serwer, który może odzwierciedlać inne punkty końcowe z pewnymi dodatkowymi funkcjami, takimi jak uwierzytelnianie lub routing.
Chodzi o to, aby scentralizować niektóre usługi, ukryć rzeczywiste serwery przed siecią zewnętrzną itp.
Sumowanie wyników
Jeśli naprawdę chcesz mieć logikę biznesową na bramie, łącząc różne dokumenty do innego dokumentu lub po prostu zmieniając żądania lub odpowiedzi, być może patrzysz na Enterprise Service Bus .
Czy agregacja jest dobra
Jest to oczywiście dyskusyjne i zależy od indywidualnych opinii. Można argumentować, że istnieje powód, dla którego (głównie) odeszliśmy od rozwiązań typu SOA / ESB. Przyczyną może być to, że poszczególne obowiązki nie były jasne i gromadziły się po stronie ESB, pozostawiając punkty końcowe „głupie”. W rezultacie ESB wie wszystko.
Podejście „REST” jest inne. Opiera się na „inteligentnych” punktach końcowych, znając ich część i upewniając się, że żadne inne składniki nie muszą znać żadnych szczegółów. Ten pomysł sam w sobie wydaje się być w konflikcie z tym, że Gateway wie więcej o odpowiedziach .
Rzeczywiście, istnieją pewne pomysły dotyczące architektury, takie jak Samowystarczalne Systemy , które opierają się na pomyśle, że każda funkcja, której potrzebuje klient, powinna być całkowicie objęta danym punktem końcowym. Nie powinien potrzebować synchronicznej komunikacji z innymi, aby spełnić żądanie w swoim obszarze odpowiedzialności. Sugeruje to również, że agregowanie wyników może przynieść efekt przeciwny do zamierzonego.
Jak zawsze jednak wszystko zależy od dokładnych wymagań.
