Is there a compelling reason to offer "batch update" version of update methods in a .NET web service?
Is there a considerable advantage over making multiple calls, asynchronous or synchronous, over HTTP?
My first impulse is to offer asynchronous calls and include a record ID in the input composite, and to push-back on the requirement to offer batch operation as a micro-optimization. Alternatively, I would request the consumer to use an iterative loop and make multiple calls.
I don't wish to make a poor suggestion.
We offer createRecord() and createRecordAsync() / createRecordCompleted (an event handler)
We toyed with the idea of creating a createRecordBatch() for about 10 seconds before we started to notice problems with it. Our createRecord() method takes in, amongst other things, a session ID, a creatorHandle for the user, and a string array containing all values. To implement a batch load, we would have to create a two-dimensional array for values, an array to store creatorHandle, and a single session ID.
Even so, our web services just act as a wedge between our external vendors and our core application. The core application does not support batch loads. Essentially what we would have been doing was mimicking a batch load to our vendors. We would have to parse their batch data into individual record creations. There was no point to offering mock features to our users that did not exist, because we would not be reducing any hits on the database. In fact, the extra work to process batch loads was taking work away from the client-side and placing it on the sever side, which felt counter-intuitive.
It made more sense to have our vendors build the logic for multiple ticket creations themselves by collecting data and making multiple individual calls to our web service methods. I believe only one of them makes asychronous calls... the rest are happy with sychronous.