Overall interesting read and perspective on how to handle concurrency in a web app. I’m a bit surprised though, normally in this situation the issue can be easily avoided by responding back to the client with the updated resource object and using that one in the client (or performing a subsequent GET on the underlying resource to repopulate it).

There is some trouble with creating sessionIds however. There are some cases when multiple resources need to be updated. This can cause a distributed transaction problem if some of these are allowed to persist but others are blocked. It also isn't clear to the client when this would happen since some times the server "automatically handles it" and other times "there's a problem".

Another issue the "multiple application tab" problem. Your user is running the same application in multiple tabs. Each of these will have a different sessionId. In those cases there can be an issue where an update in one tab prevents the other one from working. The user makes an update in Tab A, and then forgets and goes to Tab B, and makes more changes. While the commit to A works, the one in B doesn't. That's because even though both tabs may use a "web store" (like localstorage) the data was never updated. When attempting to update B, the user gets an error. At this point they may not be able to tell the difference between Tab A and Tab B, especially if the data that was changed isn't prominent.

In general it's better to use REST principles and not assume that there is a state being saved in the DB (this departs from REST and stores the user's state in the DB which is a REST antipattern). Additionally, keeping sequential operations as separate requires similar handling as to multiple users updating the same resource. So providing an optimization for multiple update by the same s seems a bit unfortunate since it doesn't solve the larger problem of "how to handle when two updates are made at a similar time by different users"