I need to set up an XData API where the client will make a request and then typically get back a bunch (5-20) of small data files (~25-30kb each). I'm thinking of a couple of approaches.
-
get back a list, then repeatedly request each file on the list via the XData service (so 2 distinct API calls)
-
simlar to (1) but instead of having to request each file from the XData service, the files are located in a folder that can be accessed via a URL, and a normal HTTP file download request can be used to grab them
-
get back a single file in response to the request that's something like a zip archive with all of the files inside of it
I'm leaning towards the first two because my app can start consuming the files as more are being fetched, while (3) delays any processing until the entire zip file is DL'd and unzipped. However, it's unclear if this is of any benefit yet since many of the files won't need to be used right away, if at all.
In this type of usage scenario, are there any other factors you might consider affecting your choice?
Some other potential factors.
- You can build a pretty light-weight XData endpoint to return just a single file, implementing (2) but above with the additional XData coverage for secured acces via a JWT, etc.
- Are you using XData to log or restrict access to these files? Is it easier to do either if they are separate?
- How often does a single client make such requests? Is it once on startup, or does a batch request come through frequently?
- How variable is the request? Always the same 5-20 files? Always different files? Can the batches themselves be cached?
- Does the order matter? Can they receive them out of order and do UI updates, or do they have to wait for a particular file in the batch before continuing?
- Getting them all at once means there might be a delay initially, but then you have them all and can proceed.
- Getting them all separately might actually take longer, but maybe UI updates can reflect on that progress. If any are delayed this may be reflected poorly in the UI. Or maybe it is better depending on whether the user is actively waiting or is oblivious to this happening.
- Returning a JSON with an array of Base64-encoded files may work just as well or better than a ZIP file.
- Server resources in compiling the batch (including compressing the outgoing stream) might be something to consider depending on how many requests are to be served simultaneously. Versus the server load of handling 5-20 simultaneous requests.
- Browsers are exceedingly efficient at handling multiple simultaneous requests. Load up https://www.actorious.com and you'll see hundreds of images downloaded, each in the 5-15kb range, all handled via separate requests. So no issues there really, just on the server end.