3đź‘Ť
The RESTful way to do it is to have the client keep track of either the Last-Modified header or the Etag header returned with the resource. Then, when it POSTs, add a header like
If-Unmodified-Since: <date-noted-from-initial-GET>
or
If-Match: <etag-noted-from-initial-GET>
If the resource has been modified on the server since the client originally downloaded it, then the server should return a “Precondition Failed” response. The client can then retrieve the current version and display something sensible to the user.
Getting tastypie to respond to those headers, though, might be a bit more difficult.
4đź‘Ť
With REST, the state of resources is managed by the server, so your idea of a sequence field is spot on. The server keeps track of which version the resource is in, and the client says which version it thinks it’s creating when it sends a new version. If the client is mistaken, the server tells it so.
Ian’s suggestion of ETags or modified dates sounds like the right way to do this, and this answer to a similar question agrees. I don’t actually have much experience of this myself.
- [Django]-NoReverseMatch for Django form
- [Django]-Overwrite an Existing Template Tag method in Django 1.8
- [Django]-Django deep serialization – follow reverse foreign key constraints
- [Django]-Creating indexes – MongoDB
- [Django]-Django Reuseable Apps