There are very few hard rules when it comes to API architecture, but many general principles on which we can rely for guidance. Here are a few which are relevant to your question: Prefer simplicity whenever there is not a clear and strong case for the complex solution. Clever solutions are fun to craft and a nightmare to maintain. Obvious solutions are not particularly fun to craft, but they're easy to reason about and maintain. So, try to be considerate of your future self! HTTP requests have overhead on both the server and client. Server load will naturally increase with more requests, regardless of response size. Clients have an upper limit on the number of concurrent connections, and there's (usually) TLS and Gzip work to be done for each request as well. Coordinating multiple HTTP responses is a complex problem. Is the response data interrelated? Will each separate response trigger a re-render? Does splitting up the request mean performing the (smaller) requests in sequence (on the client), or does it result in redundant database calls (on the server)? Does all of the response data need to be denormalized before it can be used? It's complicated. Abstractions like Promises can help reduce code complexity, but can actually increase complexity at runtime (think debugging), so there's still a cost. Parallelizing HTTP requests can reduce total response time (and therefore improve the user experience), but I would advise to avoid it unless you're certain the additional complexity is worthwhile.