How to manage versioning of resources

1

Hi,

we are trying to implement This GREAT JSONAPI Specification.

Each time a resource is updated, we want to show the version of the resource, and let user to see previous versions.

Exemple :

{
  "data": {
    "type": "articles",
    "id": "1",
    "attributes": {
      title: "first version"
    },
    "meta": {
      "version": "http://.../article/1/versions/1"
    }
    "links": {
      "self": "http://.../article/1
    }
  }
}

After updating the resource :

{
  "data": {
    "type": "articles",
    "id": "1",
    "attributes": {
      title: "modified version"
    },
    "meta": {
      "version": "http://.../article/1/versions/2"
    }
    "links": {
      "self": "http://.../article/1
    }
  }
}

Is a Link in meta is a good approch ?
How can i show a link for each version ?

after performing a GET into "http://…/article/1/versions/1"
IS self link MUST BE http://…/article/1/versions/1 ?

i dont know how to perform this.

Is JSONAPI will manage versionning of a resource ?

thanks in advance,

Jeremie

2

As a spec, JSON API has no facilities to keep track of object modifications; this is at a lower-level than the interchange format.

How you would do this would likely be modeled already in your database, correct? For instance, consider the following structure:

URL: http://…/article/1

{
  "data": {
    "type": "articles",
    "id": "1",
    "attributes": {
      "title": "modified version"
    },
    "relationships": {
      "versions": ["http://.../article/1/versions/2"]
    }
  }
}

In this structure I am implying a very specific data model. In particular, I am suggesting that you have a list of articles related to any particular article. Those articles are all of the previous revisions. How this is represented in your backing data store (i.e. SQL, Redis, etc.) is a question, but the high-level representation should be the same. For instance, in SQL, you could have a join-table which properly relates ID’s or run simply run a JOIN query directly that ultimately performs the same operation (depending on size of data, indexing requirements, etc.).

If I were to represent the JSON payload listed above as a POJO (so we can see some types!), it may look something like this:

public class Article {
    public long id;
    public String title;
    public List<Article> versions;
}

Notice that you may not want to store copies, of course, merely references to the other articles.