subbu.org

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 priori whether or not your addition is going to affect the resource you want to retrieve (contacts 11-20)?

This use case is not unique. I have come across several such use cases, and have seen similar problems being discussed elsewhere in the REST community. My first reaction was that, this use case requires a generic batch server to process these requests on behalf of the client. James Snell made a great start, and let’s say, we adopt such a solution for this use case.

Unfortunately this still leaves a number of questions unanswered.

• Atomicity: The client is asking the server to perform some writes, but is not asking that these writes be performed automatically. Why? Why is suddenly atomicity not a big deal? Is the client developer sure that he does not care about atomicity? How about the server developer?
• Ordering: The batch proposals by James Snell and the current batch model by Google execute the batch in the order the requests were composed into a batch. While processing the batch what is the batch server doing? Just waiting on IO for each request to be processed in series! Not an efficient use of CPU cycles, particularly when executing large batch requests. It does make sense to execute the batch in parallel, and compose the response once all the requests in the batch return their responses. But parallel execution can potentially alter the representations that the client would receive, particularly in the use case John Panzer describes. What is the best approach? Parallel or serial execution? Does the client developer understand the implications, and account for any oddities in the client code?
• Complexity: Is creating a batch request simpler than creating a regular HTTP request? Not necessarily. Creating batch requests is more complicated than creating simple HTTP requests. It is most likely that the server has exposed an elaborate URI space that the client is already programming against without batch. Switching to a batch solution comes at a cost for the client developer – not only for creating batch requests, but also accounting for failures, retry etc.

The bottom line is that, such use cases are real, but deserve a lot more scrutiny.

On this note, it is better to take a step back and think about the basics, such as better URI design, better resource modeling etc.

If, at the end, such use cases are deemed important and must be addressed, as I argued in Untangling the BATCH Hairball, it is worthwhile to consider if such a use case be addressed by exposing additional URIs on the resource server, or by building new resource-serving servers that wrap existing servers. Why? Because such a middle-ground could provide more precise answers to the above questions.

To conclude, we need to raise the bar for applying batch execution as a solution.