Could a relationship object have relationships

1

HI!

tl;dr : Would it be useful to be able to get chained relationships (relationships of relationship) in top-level relationships object?

I am trying to understand how the relationships object works.
I have a model with chained relations that I want to fetch. I want to present 2 use cases :

UseCase 1:
User    hasOne Profile
Profile hasOne Region
Region  hasOne Country
Country hasOne Continent

If I want to get the related Continent, I need to request my user, including profile.region.country.continent. The top-level relationship object would contain the Profile ID, I would need to look up the Profile in the Includes array to get the Region ID, and again the Region to get the CountryID and again the Country to get the ContinentID.
It is redundant and a lot of post-processing (look up in the include array), and my backend feed itself from a RDB which is not fully used :frowning:

UseCase 2:
Profile has one  Country as originCountry
        has many Country as visitedCountries
        has many Profile as friends

In this situation, what I get from this post is, if I want to get my Origin country, the countries I visited and all the countries my friends visited, I should include : friends.visitedCountries.
Such a request would give me a top-level relationships object with the originCountry and visitedCountries of mine but only the ids of my friends, and their countries in include. Here, there is big chances that the countries I will get will be redundant and, the include system allows me to get less data through HTTP.

My point

The all-flaten representation is useful, but it would be nice to be able to reach the relationships of a relationship directly in the top-level object, preventing unnecessary post-processing to reconstruct data that is represented in a relation-wise fashion on server-side. Wouldn’t it?

Thank you for reading.

2

You can but it’s not part of the relationship object.
Instead as a consumer use the includes parameter to traverse the relationships, and sparse field sets to remove extra data before your response. *Note, this should completely override default processing of your resource, so consumers will have to keep this in mind.

Alternatively, if this is functionality you would like to offer in a standard way to consumers, you can create a deep relationship and only return the items required for full linkage.

Note: A server may choose to expose a deeply nested relationship such as comments.author as a direct relationship with an alias such as comment-authors. This would allow a client to request /articles/1?include=comment-authors instead of /articles/1?include=comments.author. By abstracting the nested relationship with an alias, the server can still provide full linkage in compound documents without including potentially unwanted intermediate resources.