Developers make API calls to get data and submit data to web services. Usually, a POST or GET to a url is made, using a web library in most languages. This data is returned in the response and is then parsed by the application.

This works for the most part. Calls to the API are simple, short, and don’t usually occur too frequently. So when thousands of applications are requesting data, the server can handle it like visitors to the main website.

If you do have to make a bunch of calls to the API to get similar data (like the names of a set of users), some APIs allow you to batch them up to help reduce the number of connections. Resources are used more extensively with individual connections and additional data wraps the desired data, which can lead to a higher load on the server and more bandwidth being used.  A batched API call usually returns all the data wrapped in one wrapper and in one connection.

One would think batching would be easy to implement and better than individual calls to the API. This isn’t always the case.  Sometimes the service wants to restrict the number of requests made or you could get all their data in a matter of (milli)seconds. Other times, the API isn’t a high priority and the main website is given more of the resources.

Batching also complicates the interface of the API. Are you getting a single user’s data back, or data from a number of users. Understanding the varying response is critical to getting the right data.

The amount of data returned is reduced with a batch call, but can also present too much data at one time. If you have to download all this data at once, the connection must remain open. Making more calls may be slower, but can also help even out requests overall. If a server is hit with 10 requests for 10 users at one time versus 20 requests for 5 requests in twice the time, the data tubes aren’t filled as much all at once. It all depends on the load.  With more requests, you can determine how often a request should be made and can choose to pause or stop after each request.