Relationships "data" node

I’m struggling a lit bit in making decisions about whether to serializing the “data” node of my relationships. I’m finding my underlying data store (relational database) is a large factor in my decision (if it’s a single foreign key that i’ve already fetched, i usually include it in the payload via the relationship[name].data field). However, I’m also making decisions based on how often I’m going to use that data (as the primary client of my API).

Is it reasonable to include/exclude a specific relationship’s “data” node, based on expected usefulness?

For instance, my “article” resource has two relationships:

  • authors (many)
  • comments (many)

When fetching articles, I’m finding that I’m leaning towards using the “data” node in my authors relationship, but not the comments relationship (irrespective of includes). Both relationships will include links.self/links.related.

In this case, the reason I’m using the data node for authors is because my client application has the id of the logged-in-user available. On an “articles” list page, I can check and put badges on “My Articles” (articles belonging to the logged-in-user) authored (a little bit of a contrived example, but hopefully it helps make the point).

Is consistency of relationship data nodes important from endpoint to endpoint (or even among relationships in the same endpoint?

Thanks,
Andre

1 Like

Yes, absolutely! There’s nothing that says that you have to include "data" consistently and, as long as you’re giving clients links when "data" is absent, it seems quite reasonable to me to not include "data" if the ids would be expensive to fetch and/or your don’t think they would be particularly useful.

3 Likes