API REST - Concurrency Control and Consistency
In the development process of an API, the following situation is very popular : many users interact simultaneously to a single resource and update it. We want to avoid these situations where changes made by one client are overwritten by another without even knowing it.
Concept
A RESTful API needs to follow up some kinds of criteria which have been defined previously before being developed. One of the most important criteria is the concurrency control and consistency.
Firstly, let us introduce about concurrency control. This problematic happens whenever you have many users independently and concurrently modifying a same resource. This scenario could be illustrated in the UML diagram below.
Alice wants to make a change on the field 'description' of a seller, at the same time Bob asks for the same thing. By the time Alice wants to check her update, she will not be able to recognize the data change because it has been changed before by Bob. In general, we would like to avoid this situation since a change that is made by Alice could be overridden by Bob if Bob saves last.
Actually, Opencell’s API has no mechanism to deal with this problem. There are two possible solutions to solve this problematic, named pessimistic concurrency control and optimistic concurrency control :
Pessimistic concurrency control consists of locking a resource whenever this one is being used by a user. As soon as a user starts his update, he needs to lock it, during this time no one can change it. When the update is finished, he unlocks this resource so that it can be edited by other users. Concretely, only one user can make a change to a resource at a moment. One disadvantage of this mechanism is that the resource will be locked for a certain period of time. However, if this time is too long, it will affect other users when they cannot make changes to this data. One solution to this problem is to predetermine a reasonable amount of time for a resource to be locked
Optimistic concurrency control, on the other hand, permits many users to modify a same resource at a same time. It consists of giving different versions of a resource. The following scenario illustrated clearly this mechanism. Initially, Alice and Bob retrieve the seller version 1, noted as v1. Lately, Alice makes a change to this seller, this update is accepted by the server and noted as version v2, as there hasn't been any change on this data till now. When Bob makes a change on this data, the server will report failure because this change was made on an old version of the data. A simple solution for Bob is to retrieve the new version of the resource before doing his changes.
As mentioned above, Opencell's API does not have a mechanism to deal with this problematic, we need to discuss and choose a specific solution to implement in the product.