Resource Versioning (Discussion)

[thecoshman]

Can't think of a better way to explain what I want than this...

UI User Alice GETs an object, that payload should include the version of the entity - version x.
UI User Bob GETs the same object, also version x.
Alice edits the object in the UI and then makes a PUT request, saying they want to PUT version x.
Server confirms that version x is the current version, and thus accepts the request.
Server saves new version of object, and now stores it's current version as x+1
UI User Bob has not refreshed data.
UI User Bob makes an edit in the UI and then makes a PUT request, saying they want to PUT version x.
Server rejects Bobs payload because current version is x+1
UI User Bob must now 'GET' the resource again, now getting x+1, and then make their changes as desired.

This is mostly of concern when thinking of more users.
But, it could also be interesting if every resource we store is done via 'append only' tables.
The UI interactions are the same, but now when you edit an item, you update the version by one and POST that new 'full' resource. As long as this new version is one more than the previous, it can be accepted. By default, when you get a resource you get the latest version.

We now have a history of every resource that you ever created/edited.
Changed a peer by accident, can't recall what you had, well by golly we have a roll back behavior (which you trigger by creating a new version).
Deletion would always be a 'soft delete' sort of thing - though we could have the option to hard delete if people ever want to.