At the moment, we reserve id, type, links, and meta members in resource objects. We feel pretty dang sure these are the only ones we will ever need. However, the possibility remains that at some point in the future, we may wish to reserve another. Doing so would be additive/backwards-compatible with the spec, but it would not be backwards compatible with implementations if they are currently using that member as an attribute in their data.

There has been quite a bit of discussion around the prefixing or not-prefixing of reserved members since the inception of the spec (e.g. #313, #362, #558, #569) and we've always landed on not prefixing. I personally agree with this approach, but I'd like to propose an alternate representation for resource objects that should completely eliminate these concerns by walling off implementation-specific attributes under their own namespace.

{
  "id": "1",
  "type": "book",
  "attributes": {
    "name": "J. R. R. Tolkien",
    "date_of_birth": "1892-01-03",
    "date_of_death": "1973-09-02"
  },
  "links": {
    "chapters": {
      "self": "/books/1/links/chapters",
      "related": "/books/1/chapters"
    }
  }
}

Not only does this form prevent future conflicts, it would serve to simplify the normative language of the specification--terms like members and attributes would be reflected in the data structure itself.

Pending positive feedback from people currently implementing servers and clients I would like to make a PR for this change.