Ability to represent relationship without including the related resource

[snarkitect]

This is similar to some thinking reflected here:

• belongs to relationship won't show without preloading, but preloading is not necessary #193
• [RFC] Rework Relationships #174

We have a service boundary in our application but want to represent the JSON:API relationship. Relationships from within the service might be "includable", whereas relationships where another endpoint or service own the resource might not be.

I'll base an example off of the JSON:API example here: https://jsonapi.org/examples/

Let's say we have a CMS service that hosts our actual articles, but a separate service that really owns user information (authentication, authorization, profile data, etc.). Each article in the CMS would likely still have an author_id.

Using JSON:API. We'd still want to represent that as a relationship in a response from /articles, but we may never want to be able to include the full resource since its owned by another service.

It would be great to be able to make one request to something like /articles and see the relationship even though we have to make a subsequent request to get the actual people record

GET /articles HTTP/1.1

HTTP/1.1 200 OK
Content-Type: application/vnd.api+json

{
  "data": [{
    "type": "articles",
    "id": "1",
    "attributes": {
      "title": "JSON:API paints my bikeshed!",
      "body": "The shortest article. Ever.",
      "created": "2015-05-22T14:56:29.000Z",
      "updated": "2015-05-22T14:56:28.000Z"
    },
    "relationships": {
      "author": {
        "data": {"id": "42", "type": "people"}
      }
    }
  }]
}

GET /people/42 HTTP/1.1

HTTP/1.1 200 OK
Content-Type: application/vnd.api+json

{
  "data": {
    "type": "people",
    "id": "42",
    "attributes": {
      "name": "John",
      "age": 80,
      "gender": "male"
    }
  }
}

It would be helpful to be able to represent a relationship without exposing the ability to include that resource. Perhaps we could have the ability to hide the related view or to otherwise include the relationships portion of the payload without serializing the resource on the includes portion of the response.

[snarkitect]

@jeregrine Does this make sense? Is it on the radar?

[snarkitect]

We could also potentially solve the problem by allowing the relationship name to be overridden similarly to how fields are in the view.

Override author relationship in the view

def author(article, _conn) do
  %{ id: article.author_id }
end

It would also be good to be able to potentially disable including the data but still reflect the relationship, but that looks like a bit of a refactor by comparison.

[leepfrog]

Not sure if this addresses your use case, but the client can restrict which fields are returned on included resources by using sparse fieldsets.

eg: GET /articles?include=author&fields[people]=id,age

should return something like this for you:

{
  "data": [{
    "type": "articles",
    "id": "1",
    "attributes": {
      "title": "JSON:API paints my bikeshed!",
      "body": "The shortest article. Ever.",
      "created": "2015-05-22T14:56:29.000Z",
      "updated": "2015-05-22T14:56:28.000Z"
    },
    "relationships": {
      "author": {
        "data": {"id": "42", "type": "people"}
      }
    }
  }],
  "included": [
    {"id": "42", "type": "people", "attributes": {"id": "42", "age": 80}}
  ]
}