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.