I've been reading some articles on RESTful APIs and it got me thinking that maybe it could profit from a git architecture.
The idea would be that when you PUT to api/dragons/haku, you are (git) staging a change to the /haku resource. A summary of the currently staged data is returned by the PUT, as well as HEAD revision number to see if the live data needs to be updated. Different sections of the APIs could have their own 'HEAD' number, so that we can know when the latest dragon has been edited, but not the latest imp.
Similarly, when you POST to /dragons, you are (git) adding a dragon to the resource repository. With GET, an HTTP header could say whether you would like the staged data, the live data or the data of a particular revision.
Semantically, it could be better to add a new verb COMMIT to commit to a certain resource, but it can easily be circumvented with _post variables or headers to support interoperability. A commit message is posted along with the COMMIT verb.
On the database side, I'm