Problem/Motivation

According with the spec, the fields type and id are protected and cannot appear in the attributes or the relationships. See: http://jsonapi.org/format/upcoming/#document-resource-object-fields

We do have type and id in our payloads.

Proposed resolution

Change the name of the property to a safe name. Suggestions are:

  • entity--type and entity--id
  • resource--type and resource--id

Whenever we need to do a field change, we should note that in the metadata for that object:

{
  "type": "lorem--ipsum",
  "id": 1234,
  "attributes": {
    "resource--type": "foo"
  }
  "meta": {
    "fieldMaps": {
      "resource--type": "type"
    }
  }
}

That way consumers may build a matching representation of the object in the backend with the correct field names.

Comments

e0ipso created an issue. See original summary.

e0ipso’s picture

Title: [BUGFIX] Protect fields type and id » [BUGFIX] Protect fields: "type" and "id"
e0ipso’s picture

While this is important, I don't think it makes sense until we can have field aliases.

wim leers’s picture

e0ipso’s picture

Status: Active » Closed (won't fix)

Closing. Please continue discussion in #2846488: Explore abstracting away "Drupalisms".

alex.skrypnyk’s picture

@e0ipso

I'm not sure why this was closed. Current implementation of `jsonapi` module responses is not compliant with JSONAPI standard. This has not thing to do with other improvements and field aliases. Currently, every installation of `jsonapi` module need to alter this to make the clients work correctly, because the clients expect standard-compliant JSONAPI responses.

Please consider re-opening this.

alex.skrypnyk’s picture