I couldn’t sleep last night. So I designed a RESTful interface for version control. Yeah, that’s weird.
We already have a nice model for RESTful document storage in Amazon’s S3. But S3 doesn’t do versioning. What if it did?
A PUT to a previously-unused URI creates a new resource with version number 1.
Any subsequent PUT to that URI overwrites the resource and increments the version number.
When responding to a GET, the server sends three additional headers:
X-Version-Number: the version number being sent;X-Version-Time: the timestamp for that version; andX-Latest-Version: the latest version number available.
If the client wants the latest version, it uses a normal GET.
If the client wants a specific version, it can include either X-Version-Number or X-Version-Time in the request header. For the former, the server returns the requested version. For the latter, the server returns the latest version recorded at or before the specified time.
Hey, presto, we’ve got S3 with versioning! But it’s not a real version control system like Subversion. Every new version overwrites the previous version unconditionally. There’s no notion of diffs or conflicts.
But wait, it’s time for everybody’s favorite HTTP verb, POST!
The client can send a POST with a body containing a diff from the previous version. If there’s a conflict, the server responds with “HTTP 409 Conflict” and shows the conflicting lines in the response body. Otherwise, it’s “HTTP 200 OK” and a new version is created.
We can make this look more like a traditional source-code version control system by adding some extra headers: X-Version-Comment and X-Version-Author for recording metadata about a revision. We could also add X-Version-Changeset with a value that identifies this revision as part of a larger set of changes.
Branching. The RESTful version control system can implement branching the same way that Subversion does: each branch goes in its own directory. Add a couple more headers: X-Branch-From says what resource this resource was branched from, and X-Branch-Version says at which version of the original resource the branch occurred. Include these headers in a PUT to create a new branch, then the server will always send them in response to GETs.
Security. Meh, if you want security, do it at the server or protocol level. Adding authentication to this interface would make it much more complicated.
Honestly, it feels like HTTP was designed for this. I’ve deviated slightly from the typical REST definition of POST, but I think my use of POST here is in keeping with the spirit of REST.
I haven’t implemented this, maybe I will some time.