Skip to content

Instantly share code, notes, and snippets.

@koganei

koganei/Rest_APIs_Git.md

Last active August 29, 2015 14:04
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save koganei/a75c2276a4eb9e00fad2 to your computer and use it in GitHub Desktop.
Save koganei/a75c2276a4eb9e00fad2 to your computer and use it in GitHub Desktop.
Download ZIP
RESTful APIs + Git architecture
Raw
Rest_APIs_Git.md

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 not sure how to build it. Are there versioned databases already? or is there a way to use git with a file-based SQL system like MySQL to actually use git to version everything?

I thought it could be pretty useful to get data from certain times, and to explain the changes to the resources instead of blindly modifying our entities.

Any thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment