A opção 1 (várias chamadas assíncronas) é a melhor opção porque:
- cada chamada individual é sua própria entidade , para que você possa tentar novamente individualmente se algo falhar. Na arquitetura monolítica de "chamada única", se uma coisa falhar, você deverá fazer a chamada inteira novamente
- o código do lado do servidor será mais simples: novamente, modularidade , o que significa que diferentes desenvolvedores podem trabalhar em diferentes recursos da API
- Em um padrão típico do MVC , não faz sentido que uma chamada de API carregue vários recursos separados ; por exemplo, se você solicitar
/products
uma lista de produtos para exibir em uma página e também desejar exibir uma lista de locais onde os produtos populares são vendidos, você terá dois recursos separados: Product
e Location
. Embora eles sejam exibidos na mesma página, você não pode fazer uma chamada lógica para /products
e também devolver os locais.
- seus relatórios de registro / utilização serão mais simples na abordagem modular. Se você fizer uma solicitação
/products
e também estiver carregando locais, seus arquivos de log serão realmente confusos
- se você tiver um problema com um recurso específico, a abordagem de uma chamada fará com que a página inteira seja interrompida e não será óbvio para os usuários o que houve - e isso significa que a equipe levará mais tempo para corrigir o problema; no entanto, na abordagem modular, se uma coisa quebrar, será muito óbvio o que quebrou e você poderá corrigi-lo mais rapidamente. Também não arruinará o resto da página (a menos que as coisas estejam muito próximas ...)
- será mais fácil fazer alterações em geral se as coisas forem separadas; se você tiver cinco recursos sendo carregados por uma chamada de API, será mais difícil descobrir como não interromper as coisas quando você quiser alterar algo
O ponto principal é que os recursos são separados e, em uma API REST, retornar muitos recursos separados de um único caminho da API não faz sentido, mesmo se você estiver "salvando conexões com o servidor". A propósito, o uso de parâmetros para carregar condicionalmente (diferentes) recursos não é RESTful.
Tudo isso dito, a única opção lógica é fazer várias solicitações assíncronas para separar recursos: adote a abordagem modular !
PS - Não otimize prematuramente as "conexões com o servidor", principalmente quando as conexões HTTP estiverem incrivelmente baixas e você estiver em uma LAN. Esse tipo de pensamento, em vez de escolher o design mais simples logo de cara, vai causar problemas mais tarde.