Couple of considerations for choosing one big vs several small:
- In the single request case, you can’t do progressive data processing as the data arrives; you need to wait for the full packet to arrive before you can do anything. If it fails, you need to start everything from scratch.
- In the multiple requests case, you can do progressive data processing. However, you now have to consider the potential for multiple failures and how to recover from these.
- Multiple requests incur overhead for each request. This is additional bandwidth you app will be consuming.
- Some HTTP agents limit the number of concurrent requests to the same server, and you might need to do some logic to work around that.
- Response compression will work better for the single request case.
- Multiple requests won’t require you to allocate the full memory for your data. Granted, 640KB is not that big chunk of memory, so that might not be a big consideration for you, depending on how often you will allocate it.
- In the case of early terminate of the process (either a Cancel button or the app is terminated or the browser navigates away from your page), the single request will still finish the full response download; however, for the multiple requests case, any request your code hasn’t started yet will not be executed.
Honestly, I wouldn’t be that worried about the last two and would base my choice on 1) is progressive data processing important; and 2) what your app tolerance is for failures and partial data.