Hey there, I’m currently trying to figure out whether the API allows for compound documents that consider nested relationships.
Example:
{
"data": {
"type": "entity",
"id": "23",
"relationships": {
"parent": {
"data": {
"id": "45",
"type": "ParentEntity"
}
}
}
},
"included": [{
"type": "ParentEntity",
"id": "45",
"relationships": {
"monolith": {
"data": {
"id": "67",
"type": "Monolith"
}
}
},
"included": [{
"type": "monolith",
"id": "67",
"attributes": {
"field": "value"
}
}]
}]
}
Following the specification, I might have missed the part where it says that “included” is only allowed as a top-level member and might not appear in side-loaded data, but I might be wrong on this. Thanks in advance!
“included” will only be found at the top-level of a response, but may include data for related resources found more than one level deep from the starting resource(s).
You can use a dotted notation to refer to data included more than one step from the resources included in “data”. For example, if the monolith 67 structure had an additional relationship named “peer”, your request could include a query parameter include=monolith.peer
to cause both monolith 67 and whatever is in the peer relationship to be included.
Does that answer your question?
Of course, it’s up to the application to support the include
query parameter.
-Fred
1 Like
Yes, thank you very much for the feedback! I went through the documentation again before I read your post and came to the same conclusion:
In a compound document, all included resources MUST be represented as an array of resource objects in a top-level included
member
This pretty much specifies „included“ to be part of the top level document. Of course it makes sense to put the resource objects of the „nested“ resource linkages in there - after all they can be uniquely identified with their id
Thanks!
2 Likes