Untangling the BATCH Hairball
Here is something very interesting about RESTful batch requests. Whenever the word "batch" is mentioned, I try to probe into the meaning of batch. It turns out it does not always mean the same thing. It could actually mean one of the following three things.
1. A client wants to fetch (GET) and or write (PUT, POST, DELETE) various subsets of a coarse-grained resource.
2. A client wants to fetch (GET) a fetch non-homogeneous resources from different servers, but does not want to open up multiple connections.
3. A client wants reads (GET) and writes (PUT, POST, DELETE) across a diverse set of resources, and by the way, wants them to be done atomically.
This kind of classification helps me drive towards some conclusion.
For the first class of use cases, user filtered-GET for reads and PATCH for writes.
For the second class of use cases, build a custom or generic proxy-like GETter.
For the third, if atomicity is required, well, write an app, but avoid inventing two-phase commit over HTTP. If atomicity is not required, consider batch.
Batching - Back to Basics
In response to my post on PATCHing and BATCHing, John Panzer made a very valid comment. How can you design a resource that lets you add a contact record, then retrieve contacts 11-20 out of 100, in one HTTP round trip, assuming that you don’t know a pr…