На этот вопрос можно ответить несколькими способами:
Агрегация конечных точек
Шлюзы API в основном агрегируют другие конечные точки, не обязательно их результаты. То есть это один сервер, который может зеркалировать другие конечные точки с некоторыми дополнительными функциями, такими как аутентификация или маршрутизация.
Дело в том, чтобы централизовать некоторые службы, скрыть фактические серверы от внешней сети и т. Д.
Агрегация результатов
Если вы действительно хотите иметь бизнес-логику на шлюзе, объединяя различные документы в другой документ или просто изменяя запросы или ответы, вы можете посмотреть на Enterprise Service Bus .
Хороша ли агрегация
Это, конечно, спорно, и до индивидуальных мнений. Можно утверждать, что есть причина, по которой мы (в основном) отошли от решений типа SOA / ESB. Причиной может быть то, что индивидуальные обязанности не были ясны и, как правило, накапливались на стороне ESB, оставляя конечные точки «тупыми». В итоге ESB знает все.
Подход "ОТДЫХ" отличается. Он основан на «умных» конечных точках, зная их часть и следя за тем, чтобы никакие другие компоненты не знали каких-либо деталей. Эта идея сама по себе, кажется, вступает в противоречие с тем, чтобы заставить Gateway узнать больше об ответах .
Действительно, есть некоторые архитектурные идеи, такие как автономные системы , которые основаны на идее, что любая функция, которая понадобится вашему клиенту, должна быть полностью покрыта данной конечной точкой. Ему не нужно синхронно общаться с другими, чтобы выполнить запрос в своей сфере ответственности. Это также предполагает, что агрегирование результатов может быть контрпродуктивным.
Как всегда, все зависит от точных требований.