Due to the statelessness of the REST architectural style involving that each requests stands completely alone, leading server to never store any informations about client.
Thus, pessimistic concurrency control are not suitable because it would requires that server store which client gets the lock on a resource.
Optimistic concurrency control are then used, with the help of
Etag header. (btw, as I asked there https://stackoverflow.com/questions/30080634/concurrency-in-a-rest-api)
The main problem with an optimistic concurrency control mechanism is that you allow all the time, all clients, to perform any operations.
And i would like to avoid that without breaking the statelessness principle of REST. I mean that all clients cannot perform any operation at any time.
In my mind, it would possible with a semi-optimistic concurrency control mechanism, like that:
- Clients can request a token
- Only one token can be generated and has a limited period of validity
- To perform operations on resources (such as POST or PUT), client must give this token as part of the body (or header?) of the request. Client that don't have the token cannot do these operations.
It is very similar to optimistic concurrency control, except that only one client can do some operations (the one that got the token)... at the opposite of "all clients can do all operations".
Does this mechanism is compatible with a REST architectural style ? Does it break any of its constraint ? I was thinking to ask on SO, but this seems more an high-level question, related to software design.