Empty HasMany relationship data[] on requests without "includes"

Description

Hi folks. I’m seeing some odd behavior setting up / fetching relationships. I have two entities, subscription and pricingTier. pricingTier hasMany subscription and subscription hasOne pricingTier, which seems straightforward enough.

When requesting /api/pricing-tier, I see:

"relationships": {
        "plan": {
            "links": {
                "self": "https://localhost:5000/api/pricing-tier/1/relationships/plan",
                "related": "https://localhost:5000/api/pricing-tier/1/plan"
            },
            "data": {
                "type": "plan",
                "id": "1"
            }
        },
        "subscription": {
            "links": {
                "self": "https://localhost:5000/api/pricing-tier/1/relationships/subscription",
                "related": "https://localhost:5000/api/pricing-tier/1/subscription"
            },
            "data": []
        }
    },

…note the empty array under data for the HasMany, but not the HasOne relationship to plan

Requesting /api/pricing-tier?inclue=subscription instead gets me:

"subscription": {
            "links": {
                "self": "https://localhost:5000/api/pricing-tier/1/relationships/subscription",
                "related": "https://localhost:5000/api/pricing-tier/1/subscription"
            },
            "data": [
                {
                    "type": "subscription",
                    "id": "1"
                }
            ]
        }

…plus the “included” collection that I’d expect.

I’m a little confused as to whether this is an error somewhere in my model setup or this is by design. I think I followed the examples reasonably closely, and to make sure it wasn’t a problem with my DB-first approach, I’ve been using migrations on a fresh DB, but the problem has persisted.

Any help greatly appreciated! If it’s not by design and it’s a problem with my setup, I can provide the relevant file excerpts.

Thanks!

Environment

• JsonApiDotNetCore Version: 3.1.0
• Other Relevant Package Versions:

[maurei]

Thanks for the elaborate feedback!

So perusing the JSON API spec at https://jsonapi.org/format/#fetching-relationships-responses-200 says:

Indeed, it gets a bit confusing here. Note that in your last two post (I think you’re already aware of this), two different endpoints are involved for which the semantics are slightly different:

1. The fetching resources endpoint (section in spec) eg. /price-tiers/1
2. The fetching relationship endpoint (section in spec) eg. price-tiers/1/relationships/subscriptions

Note that for the latter the specs state:

The primary data in the response document MUST match the appropriate value for resource linkage, as described above for relationship objects.

so the (relationship) data must always be populated with resource identifier objects of every subscription related to the priceTier with id 1 (which is what you’re seeing in your last post). This makes sense: it would be odd to have a ... /relationships/ ... endpoint that does not actually reveal the related data

However, concerning the former (fetching resources endpoint): the specs are indifferent about having to include the relationship data. The specs only state that the data must a be valid resource object, for which the specs state that it may or may not include relationships objects.

In conclusion: the specs are indifferent about whether the has-one (or has-many) relationships should be included in the dataset by default for the /subscriptions (or /price-tiers) endpoint. It’s up to the framework to choose a default behaviour. Clearly, the default behaviour as implemented by JsonApiDotNetCore is not consistent, as demonstrated by your first and second post. This inconsistency is driven by your setup (in the sense that you can steer the behaviour by playing with custom implementations, I believe), but that doesn’t mean your setup is wrong: the inconsistency is undesired and can be considered a bug. This item is on the backlog.

If you have a very specific setup with a particular behaviour that you require to be different for your application to work, I can look into that specific case for you and point you towards a work around until we’ve fixed this inconsistency. In that case I would need a repo I can checkout to and fiddle around with.

[UpQuark]

Okay. I’ll take a look and see if I can make a reproduction case for you! I wanted to make sure it wasn’t by design before I went really nuts on tearing up my database configuration.

Thanks.