How do you implement a coarse-grained optimistic lock in REST?

Question

I have implemented optimistic locking for my REST resources that have 1-to-1 mapping to database tables by passing back a version number which was in the GET back through to the PUT call. If the version number changed in the database between the time I did the GET and the PUT, then an optimistic lock exception has occurred. Pretty simple design.

Now, how do I do the same for composite REST resources that map to multiple database tables? I'd like to not have to pass back multiple version fields (one for each data table that relates to the composite resource). A simplistic example of a composite resource would be /FooBar where /Foo and /Bar are non-composite resources.

I'm basically looking for an example of the REST implemetation of Fowler's Coarse Grained Locking pattern: http://martinfowler.com/eaaCatalog/coarseGrainedLock.html

Answer 1

This is what the ETag header was designed for. A very common way to implement it is to produce your response payload, make a hash of it (it doesn't have to be secure, just low-collision), and then use that hash as the value of the ETag. Note that this approach is ignorant of how many sources are involved in producing the response.

The client then sends the received ETag back in an If-Match header, which the server can use to check the freshness of the request.