Very large HTTP request vs many small requests

Solution 1:

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.

Solution 2:

Unless you are dealing with slow (very slow by today's standards) connections and really need incremental updates, do it in one request.

That gives you better efficiency for compressing the response, and avoids the overhead of the extra HTTP requests and response headers.

Solution 3:

And you have to keep in mind that the servers may have vulnerabilities with large requests.