Allow addition of relationship information without full include data

[acorncom]

This is similar to #40 but I believe is a bit different.

I have two models (MaintenanceRecommendation and Car). If I do this request (/api/maintenance-recommendations/fix-brakes?include=car), I will properly send back both the particular recommendation and the related car model.

But in my particular use case, I know the client will have the car model loaded on the client side by the time this request is made, so there is no reason to request that the full car relationship be included. The car model is also quite heavy and takes additional processing that I would like to skip.

What I'd like to do is send back hint data from the backend so that the client can properly wire the recommendation data to the appropriate car without sending the full payload for the car.

Ideally, I would call GET /api/maintenance-recommendations/fix-brakes and see the following (where the car relationship data is populated, but there is no included payload added as well):

{
    "data": {
        "id": "FancyCar-fix-brakes",
        "type": "maintenance-recommendations",
        "attributes": {
            ...
        },
        "relationships": {
            "car": {
                "data": {
                    "id": "FancyCar",
                    "type": "cars"
                }
            }
        }
    }
}

Any thoughts on that? From what I've seen in Twitter conversations with the spec author, this type of response would be valid per the spec ... It's in essence server-side hinting that the backend is allowed to add without it being required ...

[tuyakhov]

It seems like a good use case for populating relationship data. I think it's not possible to get the id of a related model without actually looking into the database and loading it. It's easy to do for 'belongs to' relationships when there is an attribute like car_id. But what about one-to-many or many-to-many relationships? Not sure if there is a simple way to retrieve that. Also, we have to keep in mind the support of different types of databases.
Maybe it will be a good solution to abstract serializing of relationships object so that it will be easier to extend or overwrite it.
What do you think?

[acorncom]

Yes, good point on the fact that it's easy to do on 'belongs to' (my scenario) but not necessarily on 'has many' relationships.

My inclination for now would be to allow this type of customization for belongs to relationships and see if we actually need it for 'has many' relationships. I suspect that the need might not be there in the same way for 'has many' relationships ... Thoughts?

As far as a good solution to abstract serializing, have you been keeping an eye on json-api/json-api#1254 ? Seems like the changes suggested there could make life more complex on the implementation side ...