I am currently creating an API and implemented a few basic REST actions such as get, update, search etc. Another program that collects data needs to synchronize these to this API. My current thought is: What would be good practice to synchronize this data?A few informations:The amount of data that needs to be synchronized is different between applications. Some may transfer 100 records a minute, others 10k records a minute. There will be a transfer limit per hour to keep the server load balanced. Additionally, requests are signed with a token to check authenticity. Here's a little pro/con list I've made just now. I'm neither sure if these are real pros/cons there nor am I sure if I should weight some of them.Option OneLoop through this data and create an API call for every record.  Pros:  integrates better with the current REST APIfailed synchronisation entries can be queued for a resendCons:  a bigger overhead because of multiple callsOption TwoBuild a package of all those data and send over that package in one call.  Pros:  less overheadjust one queryCons:  transfer error may drop all dataseparate implementation to allow 
Sending a collection of data to an API. Multiple small calls vs one big call
api design
Generally, the overhead of initiating and ending the remote request is high enough that you are going to want to batch the calls. Exactly where this line is really depends on how much data is involved here to say where your batching lines should be. It really should not be that much overhead to make the receiving system handle batches -- computers are real good at run this function again with new parameters last time I checked. From a logical perspective, would a batch be considered a transaction in the typical database sense? If so, it also makes loads of sense to let it travel and succeed (or fail) together rather than trying to work out how to spread a single logical transaction over separate physical transactions. What would push me towards doing single calls is if each request had a lot of data involved -- hundreds of KB at least -- or if things needed to be a bit more real time and you couldn't wait to build batches.