This week there was more activity around supporting batch requests over HTTP. To start with, Bill de hÓra posted a critique on why doing batch processing over PATCH is a stretch. In response James Snell posted an update to his proposal, this time using a new verb BATCH and using a multipart entity body with each part representing an independent HTTP request encoded via the application/http media type. John Panzer of Google posted some of his reactions to this idea. This activity proves that every organization exposing web services over HTTP is facing two common problems:
- Partially updating resources, which HTTP PUT can not address, and which HTTP PATCH can address reasonably well.
- Batching a series of potentially heterogeneous (i.e a mixture of GETs, PUTs, DELTEs and PATCHes) requests into single HTTP request.
I have come across lots of conversations about these use cases both within and outside Yahoo!. I find that a majority of use cases can be addressed without requiring partial updates (PATCH) or batch processing (such as via BATCH). Here is one trick – Better URI design. By making every updatable piece of data an addressable resource, most requests for partial updates can be avoided. For example, if the email address of a /person resource needs to be updated, instead of thinking of it as a partial update of the /person resource, treat is a PUT for the /person/email resource. This is not the same as partially updating the person resource, but simplifies the implementation. Note that partially updating a resource is not necessarily cheaper than fully updating the same resource.
Secondly, by making resource collections addressable (e.g. /books, /people, /addresses etc.), multiple resources can be created, modified or deleted without introducing batch semantics.
Both partial updates and batch processing introduce some extra complexity irrespective of the approach used. It is better to limit these to the rarest of rare cases subjected to cost/effort/complexity justifications.
{ 4 comments… read them below or add one }
Excellent post. BATCHing over HTTP stretches too many of the reasonable constraints. It’s much better to expose new URIs in cases where things like this are needed.
Agreed with your comments, but they only go so far. Canonical example: 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)?
I agree with your comment. Better URI is only the first step that I would take. To solve the above use case, assuming that a failure to add the contact record does not stop contact retrieval, we will need a generic batch service.
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…