In a scenario where you have to perform multiple operations at the service end, on a form submission, e.g. inserting data into multiple tables, is it better to make a single service call having a large datacontract or multiple service calls with multiple small datacontracts?
To elaborate my question further, with an example, let’s say we have a form for adding a “conference”. That form allows users to fill information about the conference e.g. ConferenceName, ConferenceDate, …., Presenters, Sponsors, etc. Since some of the information would be inserted in the conference table, some in the ConferencePresenters table and some in the ConferenceSponsors table. So would it be better to send all the data to the webservice using a single call with a large datacontract or to have separate service calls with multiple datacontracts?
Which of the two is more expensive – having a large datacontract or multiple service calls?
It’s hard to quantify better. But you could consider things like bandwidth, atomicity, service organization, etc.
For bandwidth, one big chunky request will be faster over the wire since each request adds time. Plus, the client is not waiting for n*latency for the various entities to be created before their children (for lack of a better word) are.
I assume you have a database backing your service, which would let you do this operation in a transaction. If you choose to have a chatty service, you’ll be on your own for managing rollbacks, etc.
Another important thing to consider is how your service API is designed. Does the chunky operation make sense? If you find your chunk growing with optional operations, you could factor those out. If you find that 2 apis are always called together and make sense to combine, combine them.
So, you’ll probably find that having a large data contract is more performant for operations like you mentioned above (Creation of a conference with sponsors, etc.), but you have make sure the performance boost is worth the tradeoffs of having such a big, specific api call.