Concurrency control is managed by the HTTP standard mechanism provided with eTags.
•For most resources, any GET request performed on the resource is sending back the eTag associated to the current state of the resource.
•Any update requested on the resource (POST, PUT, PATCH, DELETE) MUST include the former eTag to allow changing the resource.
Server behaviour:
•In case of a missing eTag in an update request, the request is rejected: 428 Precondition Required
•In case of present eTag, the given eTag is compared to the eTag associated with the resource in the datastore.
oIf the eTag is the same, the update request is accepted and processing continues (other errors in the input may prevent the update from being performed)
oIf the resource has been changed in parallel by another client, the stored eTag would have been changed, and the update requested is rejected: 412 Precondition Failed
The client in error MUST then:
1.Refresh its previous representation to synchronize its view with latest changes
2.Apply the requested changes to the latest representation (if they are still valid)
3.Send a new update request with the update representation
This stateless mechanism prevents unwanted overwrite of changes done in parallel by two clients on the same resource.
