Marco is spot on, in saying that the answer depends on your architecture, and what follows is good advice, on how you should approach towards the 'right' answer.

Extending upon what he said; one should also consider whether there are any intermediary API calls before you return a result. If these API calls are to third party services, which have rate limits on the number of API calls one can make; in such instances, the "1 JSON" return would be preferential.

To conclude; quoting Marco —

...decide for either based on facts, not on advice and speculation

In my opinion, the answer highly depends on your architecture. If you have several small services for different kind of things, then you might go for multiple API calls. However, what's one of the most important goals of web development today? UX. You should try to develop an approach which is fast; and if both are fast, use the approach which fits your architecture better. Hence, you might consider one call, which contains everything, if all five calls finish quickly. Serializing objects does not take as much time as some may think, and multiple API calls always include HTTP overhead, which in general is a lot more expensive than a call to JSON.stringify() .

So, to put it in a nutshell, do both and do benchmarks. Then decide for either based on facts, not on our advice and speculation.

If you have these 2 choices only ... 5 calls with 20 Objects each and single call with 100 Objects ..

then selecting 5 json calls with 20 objects is a better choice .. why ?

1 . Time consumed in generating these objects. Time consumed in generating 20 objects in one go will be much more lesser than generating 100 objects.. no matter what business logic is there.

2 . While user is waiting for response.. 5 calls will keep the waiting time to minimum possible showing data progressively .. one by one . Its better to show data progressively instead of showing data at once after a long wait.

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:

1. 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!
2. 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.
3. 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.