Is it a good idea to merge multiple HTTP requests to save bandwidth?

Question

I am preparing a single page application that would be sometimes used over slow mobile connection. Some of its part are quite heavy in terms of API requests (fetching ten different resources for a new screen display).

Now, is it a good idea to merge these services to one that provides all required data, but is not as "pure" in terms of REST principles? Are there significant performance gains to be expected?

Answer 1

One of the advantages of REST is the ability to cache the requests via traditional http caches (assuming that these are cacheable requests).

When you have single, larger, less frequently used, and possibly different requests (I'm going to fetch items a,b,c,d this time and items a,b,d,e next time) you make the request more likely to be a cache miss and get expired from a cache that may be sitting somewhere between you and the source.

Given the two sets of requests mentioned above, the second request may have a 75% cache hit rate and be substantially faster fetching just e, rather than all four things.

Note that this may not be immediately apparent to people using it as the person who does the first set of cache miss requests will still have the cache misses.

This isn't to say that it would be ideal on a mobile network connection where one is less likely to get non-local cache hits. But for hot spots or other wifi situations, the cache hits could be much more useful.

Much of this, again, is subject to how your application works. Is it asking for all this data at startup? or are we talking about a page load where response time expectations are different?

The ideal thing to do would be to test this to see how your application preforms in a variety of situations. Consider setting up a situation where you've bound your mobile device to a local wifi network that you can monitor (that is just the first hit on google) and simulating a bad internet connection to see how things actually work (or don't) and which one has the best performance.

Answer 2

Your intuition is somewhat correct -- by and large making fewer requests is certainly preferable; chunky APIs tend to be better. Especially with spotty connectivity where you can see some work and some fail creating nightmarish fallback scenarios as nothing can rely upon anything.

There is one big caveat -- you can get way too chunky and your calls and responses become bloated. For example it might make sense to have one big call when you first hit a page and then have updates stream in in smaller bites rather than forcing a big page refresh every time you want data.

Or, you will want to do it both ways in all likelihood.

Answer 3

Check out this Dropbox Tech Blog article.

There they describe in detail on why and how they implemented exactly the solution you proposed for retrieving the thumbnails for all your pictures. It should be said that they do measure performance to see if it's worth the trouble, and apparently it is.

Short summary:

The Dropbox website has to load hundreds of thumbnails. Due to limitations in some browsers, not all thumbnails are loaded in parallel (the requests are queued). They wanted to use SPDY, but were unable to do so because parts of their system do not support it yet. In the end they used batch requests over HTTP, which return multiple thumbnails per response in a compressed form. Overall page load time improvement was 40% according to their results.

Answer 4

In short: Your approach is somewhat correct and could benefit from a wrapper Service.

This service will combine existing single calls into one service side method. Doing that by combining calls from client to service side & utilizing all single, atomic, restful calls that you probably have in place by now.

Thus, you would continue to have benefit from REST as the ability to cache the requests.

However, at the end point it will all boil down to the service/server infrastructure performance and client environment that should consume it.