Publishing, Versioning and Persistence

The current version of the resource must always be available at the same URL, unless it moves (send a "301 Moved Permanently" response to redirect to the new URL) or is deleted (send a "410 Gone" response).

If the document is updated, a new version of the resource must be created. Each existing version of the resource must remain available at a unique URL.

Each version of the resource must link to the previous, next and current versions of the resource.

Accomplishing this should be simple:

Assign a unique file name to each version of the resource.

Create a symlink with a file name that represents the "current" version of the resource, pointing to the appropriate file for the current version.

When a new version of the resource is created, add a "previous version" link from the new version, and update the "next version" link from the previous version.

When a version of the resource is deleted, leave the file as a tombstone, set a property to mark that this version has been deleted, and remove any other properties that should be deleted. Update the next/previous version links in nearby versions, and update the "current version" symlink, if needed.

To change the "current" version, e.g. to roll back to a previous version, simply change the "current version" symlink to point to that version.

This example uses files in a file system, but would work equally well with objects in a database. It's quite similar to how Freebase and Git (and presumably any system which allows any specific version of a resource to be checked out as the "current" version) work, except perhaps for a separate index to handle the relationships between different versions.