Skip to content

proposal to reserve "attributes" member at top level of resource objects #573

@tkellen

Description

@tkellen

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      pFad - Phonifier reborn

      Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

      Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


      Alternative Proxies:

      Alternative Proxy

      pFad Proxy

      pFad v3 Proxy

      pFad v4 Proxy