# Relationships within abstract relationship **URL:** \ **Category:** Uncategorized\ **Created:** [November 20, 2017, 11:01pm UTC](https://discuss.jsonapi.org/t/relationships-within-abstract-relationship/1158 "2017-11-20T23:01:24Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![michaelhibay](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/michaelhibay/32/405_2.png) [@michaelhibay](https://discuss.jsonapi.org/u/michaelhibay)\ **Post date:** [November 22, 2017, 9:07pm UTC](https://discuss.jsonapi.org/t/relationships-within-abstract-relationship/1158/3 "2017-11-22T21:07:36Z")
Haha, alright I’ve been busy doing conference work and starting a new job but I’ll see what I can do here to help. 😃 I’m not sure if this is the API you’re working with or a contrived example, but the problem here looks like you want the cars relationship to be polymorphic, and then utilize a feature of {json:api} which doesn’t support it. If you [look here](http://discuss.jsonapi.org/t/relationship-uris-for-special-helper-uris/943), you’ll see some discussion from a while back where I make a bunch of points about resources not being objects. The data shaping capabilities of {json:api} are not polymorphic, and are shaped by expected structure of the relationship hierarchy. This is OK and a really good design, as it is a motivator to keep the design simple and think about the design from another perspective. Consider this, if you have a polymorphic ambiguous payload being returned to the consumer client, how much duplication of business logic would you expect that client to carry out? An ideal application would create a model completely reactive to the data returned, and by including this ambiguity you would _require_ your clients to tightly couple themselves to your data model to simultaneously support all response messages for your resource model. However, if the calling agent were to filter and explicitly understand the resource representation it was going to receive, it would be much easier to make changes to any particular representation or its client side handling without the addition of cyclomatic complexity. My suggestion would be to refactor this in some way to allow for data shaping when filtering, or break it up into multiple requests. The other option if you control the client and the consumer, is to remember you control the default shape of the data so you could simply `/parkings/{parking_id}?filter[type]=cars,trucks` to get whatever shape you want. You could make this work within spec, but I think it really exposes an underlying flaw in the API design. Resources are not objects. I hope this helps! --- _[View the full topic](https://discuss.jsonapi.org/t/relationships-within-abstract-relationship/1158)._