Do not support to include related ressources as attributes #10
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@IanVS do you have another pair of eyes? I'm not a hundred percent sure that I understood it correctly. |
|
Yeah I'll give it some review tonight. |
|
It's been a long time since I've looked at any of this, but I think my goal was to shove the related data into the attributes instead of as a compound document. You've pointed out this is incorrect, and the section I linked to in the spec was regarding |
| t.ok(_.isArray(body.included), 'Top-lebel member included is an array'); | ||
| t.ok( | ||
| // all ressources in body | ||
| body.data.every(function (ressource, index) { |
There was a problem hiding this comment.
resource should be spelled with one s (throughout, including includedRessource, mainRessource, etc. )
A related ressource should not be included as an attribute value: > Although has-one foreign keys (e.g. author_id) are often stored internally > alongside other information to be represented in a resource object, these > keys SHOULD NOT appear as attributes. Resource objects have a *relationships* property which should describe it's relationships. Relationships could be described by link objects or resource linkage. Resource linkage must be used if it's a compound document. Of course an attributes value may be a JSON object or an array: > Complex data structures involving JSON objects and arrays are allowed as > attribute values. However, any object that constitutes or is contained in > an attribute MUST NOT contain a relationships or links member, as those > members are reserved by this specification for future use. Better explained in these these issue: json-api/json-api#902 > The case that is most correct is the last one (i.e. relationships are > always present). The only time when a relationship shouldn't be present > is if it's been filtered out with the ?fields parameter. In this sense, > relationships are just like attributes. > > To your point about the possible overhead of including the relationship > ids in to-many relationships: this is exactly why "links" can be used as > a substitute for "data"!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A related ressource should not be included as an attribute value:
Resource objects have a relationships property which should describe it's
relationships. Relationships could be described by link objects or resource
linkage. Resource linkage must be used if it's a compound document.
Of course an attributes value may be a JSON object or an array:
Better explained in these these issue:
json-api/json-api#902