The key to design this sort of interaction is to try and work with resources of same type, e.g. batch actions only against wheels rather than batching actions against wheels and cars and drivers, etc. A sample request for batching actions against a "wheel"
resource - create a special controller on the wheels collection and POST a special data contract modeled explicitly for taking actions against wheels.
POST /cars/12/wheels/batch
<wheels-actions>
<to-create>
<wheel-data>...data ...</wheel-data>
<wheel-data>...data ...</wheel-data>
</to-create>
<to-update>
<wheel>...data ...</wheel>
<wheel>...data ...</wheel>
</to-update>
<to-delete>
<wheel-del> ID and Version </wheel-del>
<wheel-del> ID and Version </wheel-del>
</to-update>
</wheels-actions>
To be very orthodox on REST, the returned location header should be the wheels collection resource: "/cars/12/wheels", from where you can get the newly created representations and their links. However, it's more constructive to return in the POST response
some data regarding the newly created resources. But if the client would anyway refresh "/cars/12/wheels", then you can skip returning special data in the response, the location header would suffice.
Having a single payload you can now have the service handle everything in a single transaction.
If you need to do batching on resources of different types, just design an application-specific controller resource and specific data contracts and do POST on it. It'd be better not to do it though :)
neaflo
Member
3 Points
13 Posts
Re: Batching Web API calls
May 26, 2012 12:39 PM|LINK
The key to design this sort of interaction is to try and work with resources of same type, e.g. batch actions only against wheels rather than batching actions against wheels and cars and drivers, etc. A sample request for batching actions against a "wheel" resource - create a special controller on the wheels collection and POST a special data contract modeled explicitly for taking actions against wheels.
POST /cars/12/wheels/batch
To be very orthodox on REST, the returned location header should be the wheels collection resource: "/cars/12/wheels", from where you can get the newly created representations and their links. However, it's more constructive to return in the POST response some data regarding the newly created resources. But if the client would anyway refresh "/cars/12/wheels", then you can skip returning special data in the response, the location header would suffice.
Having a single payload you can now have the service handle everything in a single transaction.
If you need to do batching on resources of different types, just design an application-specific controller resource and specific data contracts and do POST on it. It'd be better not to do it though :)