{"action":"opened","issue":{"url":"https://api.github.com/repos/json-api/json-api/issues/573","labels_url":"https://api.github.com/repos/json-api/json-api/issues/573/labels{/name}","comments_url":"https://api.github.com/repos/json-api/json-api/issues/573/comments","events_url":"https://api.github.com/repos/json-api/json-api/issues/573/events","html_url":"https://github.com/json-api/json-api/issues/573","id":70721134,"number":573,"title":"proposal to reserve \"attribute\" member at top level of resource objects","user":{"login":"tkellen","id":1004324,"avatar_url":"https://avatars.githubusercontent.com/u/1004324?v=3","gravatar_id":"","url":"https://api.github.com/users/tkellen","html_url":"https://github.com/tkellen","followers_url":"https://api.github.com/users/tkellen/followers","following_url":"https://api.github.com/users/tkellen/following{/other_user}","gists_url":"https://api.github.com/users/tkellen/gists{/gist_id}","starred_url":"https://api.github.com/users/tkellen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tkellen/subscriptions","organizations_url":"https://api.github.com/users/tkellen/orgs","repos_url":"https://api.github.com/users/tkellen/repos","events_url":"https://api.github.com/users/tkellen/events{/privacy}","received_events_url":"https://api.github.com/users/tkellen/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-04-24T15:35:16Z","updated_at":"2015-04-24T15:35:16Z","closed_at":null,"body":"At the moment, we reserve `id`, `type`, `links, and `meta` at the top level of resource objects. We feel pretty dang sure these are the only keys we will ever need. However, the possibility remains that at some point in the future, we may wish to reserve another top level key. 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 key as an attribute in their data.\r\n\r\nThere 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 and alternate representation for resource objects that should completely eliminate these concerns by walling off attributes under their own namespace.\r\n\r\n```json\r\n{\r\n  \"id\": \"1\",\r\n  \"type\": \"book\",\r\n  \"attributes\": {\r\n    \"name\": \"J. R. R. Tolkien\",\r\n    \"date_of_birth\": \"1892-01-03\",\r\n    \"date_of_death\": \"1973-09-02\"\r\n  }\r\n}\r\n```\r\n\r\nNot only does this form prevent future conflicts, it would serve to simplify the normative language for the specification--terms like `members` and `attributes` would be reflected in the data structure itself.\r\n\r\nPending positive feedback from people currently implementing servers and clients I would like to make a PR for this change."}}