REST API Design - Fetching multiple(1000) records

Question

I have a web application and have to fetch 1000 records using a REST API. Each record is around 500 bytes.

What is the best way to do it from the following and why? Is there another better way to do it?

1>Fetch one record at a time. Trigger 1000 calls in parallel.

2>Fetch in groups of 20. Trigger 50 calls in parallel.

3>Fetch in groups of 100. Trigger 10 calls in parallel.

4>Fetch all 1000 records together.

Answer 1

As @Dima said in the comments, it really depends on what you are trying to do.

How are the records being consumed?

• Is it a back end process to process or program to program communication? If so, then it depends on the difficulty of processing once the client receives it. Is it going to take them a long time to process each record? 1 ms per record, or 100ms per record? This option depends entirely on possible processing time per record.

• Is there a front end consuming this for human users? If so, batch requesting would be good for reasons like paginating results. In such cases, I would go with option 2 or 3 personally.

In general though, depending upon the sheer volume of records, I would recommend considering batching requests (by triggering fewer calls). Heuristically speaking, you are likely to get better overall network throughput that way.

If you add more specifics, I'll happily update my answer, but until then, general will have to do!

Answer 2

Best for what case? What are you trying to optimize?

I did some tests a while back on a similar situation, with slightly larger payloads (images), where my goal was to utilize network efficiently on a high-latency setup (across continents).

My results were that after a minimal amount of parallelism (like 3-4 threads), the network was almost perfectly saturated. We compared it to specific (proprietary) UDP-based transfer protocols, and there was no measurable difference.

Anyway, it may be not what you are looking for, but sometimes having a "dumb" http endpoint is good enough.