Can relationships hold attributes as an alternative to using included?

1

In the documentation it is unclear as to what the rules are for relationships.

Consider:

{
  "data": {
    "attributes": {
      "name": "John Doe"
    },
    "relationships": {
      "company": {
        "type": "companies",
        "id": "1231",
        "attributes": {
          "name": "Foo Bars Inc",
          "created-at": "2015-10-23 12:32:00Z"
        }
      }
    }
  }
}

I understand that I could use the included field, but as I stated before, the docs are unclear on this question.

The schema json yells when I include attributes in the relationships field. Is this intentional?

2

I believe you can’t.

The spec mentions that you can include as data a resource linkage http://jsonapi.org/format/#document-resource-object-linkage

In your example you the type for that linkage will be aresource identifier object http://jsonapi.org/format/#document-resource-identifier-objects which will be linking one of the objects that can be found in the included resources.

{
  "data":{
    "type": "users",
    "id": "1",
    "attributes": {
      "name": "John Doe"
    },
    "relationships": {
      "company": {
        "links": {
          "self": "http://foo.com/users/1/relationships/company",
        },
        "data": {
          // Resource Identifier Objects - http://jsonapi.org/format/#document-resource-identifier-objects
          "type": "company",
          "id": "1"
        }
      }
    },
    "links": {
      "self": "http://foo.com/users/1"
    }
  },
  "included": [
    {
      // the resource linked in data.relationships.company.data
      "type": "company", 
      "id": "1" ,
      "attributes": {
        "name": "Foo Bars Inc",
        "created-at": "2015-10-23 12:32:00Z"
      }
    }
  ]
}
3

This should probably be clarified in the spec. I can’t be the only one with this problem.

4

Should we open an issue on the repo to discuss how the wording could be improved?

5

For future reference @abuiles interpretation that this is not allowed is correct. (I’m one of the spec’s editors.) A PR with clarifying text is always welcome :slight_smile: