Existem várias maneiras pelas quais esta pergunta pode ser respondida:
Agregação de terminais
Os gateways de API geralmente agregam outros pontos de extremidade, não necessariamente seus resultados. Ou seja, é um servidor único que pode espelhar outros pontos de extremidade com algumas funcionalidades adicionais, como autenticação ou roteamento.
O objetivo é centralizar alguns serviços, ocultar os servidores reais da rede externa etc.
Agregação de resultados
Se você realmente deseja ter lógica de negócios no Gateway, reunindo documentos diferentes para outro documento ou apenas alterando solicitações ou respostas, talvez esteja procurando um Barramento de Serviço Corporativo .
Se a agregação é boa
É claro que isso é discutível e depende de opiniões individuais. Alguém poderia argumentar que existe uma razão pela qual nos afastamos (principalmente) das soluções do tipo SOA / ESB. Esse motivo pode ser porque as responsabilidades individuais não eram claras e tendem a se acumular no lado ESB, deixando os pontos de extremidade "burros". Eventualmente, resultando no ESB sabendo tudo.
A abordagem "REST" é diferente. Ele se baseia em pontos de extremidade "inteligentes", conhecendo sua parte e garantindo que nenhum outro componente precise conhecer nenhum dos detalhes. Essa ideia em si parece estar em conflito com a divulgação do Gateway sobre as respostas .
De fato, existem algumas idéias de arquitetura, como Sistemas Autônomos , que se baseiam na idéia de que qualquer função que seu cliente precisaria deve ser coberta completamente por um determinado terminal. Não deve precisar de comunicação síncrona com outras pessoas para atender a uma solicitação em sua própria área de responsabilidade. Isso também sugere que a agregação de resultados pode ser contraproducente.
Como sempre, tudo depende dos requisitos exatos.
