Making expensive attributes only available when requesting a single resource

1

I have a resource type with an attribute that is very expensive to calculate (incurs a separate database query). Thus, I don’t want this attribute to be available when requesting a collection, because it would incur an extra query for each resource (n+1 query problem). However, I want clients to be able to request any one of the resources individually to get the expensive attribute.

This would manifest as something like:

GET /api/users ->
{
    "data": [
        {
            "type": "users",
            "id": "1",
            "attributes": {
                "name": "Bob"
            }
        },
        {
            "type": "users",
            "id": "2",
            "attributes": {
                "name": "George"
            }
        },
    ]
}

GET /api/users/1 ->
{
    "data": {
        "type": "users",
        "id": "1",
        "attributes": {
            "name": "Bob",
            "expensiveAttribute": "value"
        }
    }
}

Is there any theoretical issue with having the attribute available when resources are retrieved individually but not when they are listed within a collection?

Is there an alternative approach that would be preferable? I have thought about implementing a new resource type which represents the additional data, with the ID corresponding to the original resource ID, but this feels kind of hacky to me.

2

I would isolate that attribute by making it a relationship.

3

You can use sparse fields to exclude that field and include only ones that you need.
https://jsonapi.org/format/#fetching-sparse-fieldsets

4

The problem with a standard sparse fieldsets implementation is that the consumer could opt-in to show the field on collections of resource - which is what I am trying to avoid, since the field is expensive to compute and loading it for 20 resources in one request could blow out the request time significantly, use up server resources, etc.

And I suppose the same issue exists if the attribute is isolated as a relationship - the expensive relationship could still be included when requesting a collection of resources.

What I am wondering is if it would be allowable according to the spec to have a field only become available (whether it’s requested in a sparse fieldset or not) when requesting a single resource?

5

Hm, I have a feeling that’s not a good mindset, I mean, resource is a resource and it should have the same response/features across all enpoints (/api/users, /api/users/1, /api/posts/1/relationships/user/1), otherwise client that consume that api could run into a sync problems (state transfer).
Things like this should be explicit and documented.
Maybe you can check how graphiti does it https://www.graphiti.dev/guides/concepts/resources#extra-fields