I’m asking as the author was not in fields[articles]=title,body.
Note the relationship was not included (as expected) but what is the use of getting the author included?
author is the name of the relationshiparticle -> people, but the resource type is people.
The query string starts out with include=author&.... I don’t think it’s explicitly stated, but the most sensible parsing order of the different data shaping capabilities goes include -> filtering / sorting / pagination -> sparse fieldsets.
The relationship, and resource identifier object data is required for processing and full linkage for the response documents, sparse field sets just provides a means to limit the representation clutter to a minimum set in addition to the requirements of the format and provided parameters.
In other words, I look at sparse field sets as a representation post-processor. It isn’t required to be implemented this way of course, but that is the order of precedence I see in the specification.
Yes, author is the relationship name.
As the author is not included in the fields of the articles resource query param (fields[articles]=title,body) the relationship is not included in the response.
But isn’t it strange that it is in the included?
But as you explain it, is also a possible interpretation of the spec.
Note: Because compound documents require full linkage (except when relationship linkage is excluded by sparse fieldsets), intermediate resources in a multi-part path must be returned along with the leaf nodes. For example, a response to a request for comments.author should include comments as well as the author of each of those comments .
Thus this example seems correct. It is a bit of a weird request though, it might be nicer to use GET /articles?include=author&fields[articles]=title,body,author&fields[people]=name and have the relationship linkage in the response as well.