|
The UUID apporoach seems to be fine but, it relies on the app developers understanding that a UUID should be generated before he stores his data to the cache. If he for some reasons generate the UUID anew all the time he tries to send the data to the server this won't help us in anyway.
Generating the UUID on the DB will led to the same issue as the already generated PK. Beside it could lead to some strange issues if two separate clients create the same UUID for any reason.
Two possible solutions while thinking about this for a few secs:
1. We could offer a new resource /transactions with the typically scaffolding (CRUD) mechanism that allows to initiate a transaction and returns an unique id. This id could be used to ensure all given data is unique as long as the transaction is valid. The transaction will timeout and rollback all work done so far if a client loose the connection again (sticky for a session). A huge drawback here is the amount of data that needs to be cached by the server to asure uniqueness of the data during this period or implementing a machnism to rollback all already stored data in the DB.
2. Offer a batch operation for syncing offline data. This would reduce chattiness of the client b/c he can send all changes within one call and we could perform validations (like uniqueness) of the content (Facebook is offering something like this https://developers.facebook.com/docs/graph-api/making-multiple-requests/).
These are just my two bits to this. Maybe I'll find some other solutions while cycling this around in my head for a while ![]()
|
