CODEWITHSUNDEEP
json-apicoding-style
gjunkie
gjunkie

Reputation: 828

Should JSON API entities include a relationship for its parent?

If we have, say, a blog with posts, and each post can have comments, and each comment a related user. Is it against convention, if I request the comment, to include both the user and the post in the relationships?

data: {
  type: 'comments',
  id: '1',
  relationships: {
    post: {...}, //should this be here?
    user: {...},
  }
  attributes: {...},
},
included: {...}

Upvotes: 3

Views: 5135

Answers (3)

paulsm4
paulsm4

Reputation: 121799

Should JSON API entities include a relationship for its parent?

I assume that's entirely up to you!

If your JSON is defined by some third party, then you have to live with what they gave you. Please post details on how the JSON is specified.

Otherwise, if you're "inventing" the format yourself:

  1. One possibility is to have a relationships: field with a link to the "parent".

  2. Perhaps a better solution might to invent a "container" (perhaps a simple array!) to hold your "records".

  3. If this were a database, I'd have a "posts" table, and a "comments" table. The "comments" table would have a "Post ID" column as a foreign key into the "posts" table.

Upvotes: 0

jelhan
jelhan

Reputation: 6338

JSON API specification does not make any requirements on the attributes and relationships being included in a resource object. The specification is just saying how they must be formatted if they are included. If I did not missed anything, specification does not even require that all resource objects of the same type must have same attributes and relationships.

But I would argue that there isn't any value in not including the relationships. JSON API specification does not require a relationship object to include resource linkage data. On the contrary it's only talking about resource linkage data in context of a compound document, in which it's used "to link together all of the included resource objects without having to GET any URLs via links."

It's totally valid and could be considered best practice to only provide related resource link if the related resources are not included in the payload. Constructing such a link would not put any workload on your server since it does not require to query the database. It also does not make any relevant difference in payload size.

An example of a payload using both techniques would look like this. It assumes that the request explicitly asked to include related user using include query param.

// GET https://examples.com/api/v1/comments/1?include=user

{
  data: {
    type: 'comments',
    id: '1',
    relationships: {
      post: {
        links: {
          related: 'https://examples.com/api/v1/comments/1/post'
        }
      },
      user: {
        data: {
          type: 'users',
          id: '2'
        },
        links: {
          related: 'https://examples.com/api/v1/comments/1/user'
        }
      },
    }
  },
  included: [
    {
      type: 'users',
      id: '2',
      attributes: {
        name: 'John Doe'
      }
    }
  ]
}

You may also want to include a relationship link, which "allows the client to directly manipulate the relationship." Update relationships chapter of spec gives a deep dive into what you could accomplish using relationship links.

Upvotes: -1

Stefano Coletta
Stefano Coletta

Reputation: 730

As paulsm4 correctly stated: "it is up to you".

But I can give you some advice about that.

In such situations, you can give the caller of the API the choice of having such links or not via a querystring flag, like

?relationships=post,user

In this case, if you do not specify the relationship flag, you'll get the simple comment data or you can decide to give them all; in the second case, you can use relationships as a sort of filter.

In some APIs, I've seen also a more invasive approach: embed the related object directly in the returned JSON.

With the same technique as before:

?embed=post,user

This should produce an embedded JSON object in the current JSON reply including the original objects just as you were asking something like "GET /post/123" or "GET /user/456" separately. This can be handy in some situations.

Often this flag is named "expand" denoting same or similar behaviour.

For an example open this API documentation from Atlassian and search for "expand".

It does exist an old "standard" for your problem called HAL that speaks about linking and embedding in REST APIs.

Even the Wordpress API offers such features, give it a look in the official documentation.

An alternative to this is to rewrite the entire API in GraphQL leveraging the REST approach.

Upvotes: 3

Related Questions