# Modelling a resource hierarchy that is not consistent

**URL:** <https://discuss.jsonapi.org/t/modelling-a-resource-hierarchy-that-is-not-consistent/1596>\
**Category:** Uncategorized\
**Created:** [May 21, 2019, 11:43am UTC](https://discuss.jsonapi.org/t/modelling-a-resource-hierarchy-that-is-not-consistent/1596 "2019-05-21T11:43:31Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![skaaptjop](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/skaaptjop/32/619_2.png) [@skaaptjop](https://discuss.jsonapi.org/u/skaaptjop)\
**Post date:** [May 21, 2019, 11:43am UTC](https://discuss.jsonapi.org/t/modelling-a-resource-hierarchy-that-is-not-consistent/1596/1 "2019-05-21T11:43:31Z")

</div>

I have a resource model that, as it travels down the related resource hierarchy, becomes potentially inconsistent and am looking for a decent way to model it in a standard way.

Say I have a nested resource: **items** within a **product**. Items and Products have unique type and IDs. Simple so far.

Then I have a second concept which extends some behaviour or rules around the items, in this case grouping them together so that when a **Quote** is built, only one item from a group may be chosen.

Conceptually this would look like:

```
Product
 - item A1
 - item B1
 - grouping C (one of)
    - item C1 
    - item C2

```

This grouping is what I am trying to figure out how to model to fit the spirit of the json-api spec.

### My attempt

I promote the “grouping” concept to a resource that can be linked as a relationship:

```
{
  "data" : { "type": "products", "id": 1, },
  "relationships": {
    "items": { 
      "links": { 
        "self": "http://example.com/products/1/relationships/items" 
        "related": "http://example.com/products/1/items" 
      }
      "data": { "type": "items": "id": 100 } }
  }
}
----
{
  "data" : { "type": "items", "id": 100 },
  "relationships": {
    "grouping": { 
      "links": {
        "self": "http://example.com/products/1/items/relationships/grouping",
        "related": "http://example.com/products/1/grouping/22"
      }
      "data": { "type": "grouping": "id": 22 } 
    },
  }
}

```

* * *

```
{
  "data" : { "type": "grouping", "id": 22 },
  "relationships": {
    "items": { ... }
}

```

This seems to work in the sense that the items and groupings can be specified, created, updated and identified individually.

My problem here is that _grouping_ only has context within a _product_. There is no [http://example.com/grouping/22](http://example.com/grouping/22) endpoint, it only exists within product/1.

That seems to be OK after I read [367](https://discuss.jsonapi.org/t/composite-id-inside-the-resource-object/367) and others. It seems as though the suggestion was to define grouping as type _product\_grouping_ and then build a composite key that is unique to the product+grouping combo. This is fine, grouping is unique to a product.

This has me thinking on how to handle the resource linkage…

If I define “grouping” as existing within product then it can only be reached as

- `http://example.com/product/1/grouping/22`
- with { “data”: { “type”: “product\_grouping”, “id”: \<hash of 1\_22\> } }

Is this assumption correct? There would be no `http://example.com/grouping/22` ?  
Can I safely assume that resource linkage doesn’t imply that a URL can be built from type and ID, only that it can be looked up in a compound document?

My other problems here is that the poor client has to figure out this hierarchy by itself so perhaps one could add a _groupings_ relationship to the product itself.

* * *

I hope this is clear. It has been quite hard for me to describe exactly what I am struggling with conceptually as there a few concepts at play here.