# Cycles in relationships

**URL:** <https://discuss.jsonapi.org/t/cycles-in-relationships/1649>\
**Category:** Uncategorized\
**Created:** [July 19, 2019, 6:36pm UTC](https://discuss.jsonapi.org/t/cycles-in-relationships/1649 "2019-07-19T18:36:06Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Geoff](https://avatars.discourse-cdn.com/v4/letter/g/a3d4f5/32.png) [@Geoff](https://discuss.jsonapi.org/u/Geoff)\
**Post date:** [July 19, 2019, 6:36pm UTC](https://discuss.jsonapi.org/t/cycles-in-relationships/1649/1 "2019-07-19T18:36:06Z")

</div>

Under [Compound Documents](https://jsonapi.org/format/#document-compound-documents) the spec says:

> In a compound document, all included resources **MUST** be represented as an array of [resource objects](https://jsonapi.org/format/#document-resource-objects) in a top-level `included` member.

Later it says:

> A [compound document](https://jsonapi.org/format/#document-compound-documents) **MUST NOT** include more than one [resource object](https://jsonapi.org/format/#document-resource-objects) for each `type` and `id` pair.

In the event of cycles in the relationship graph, I’m not sure it’s possible to comply with both of these in a reasonable way. In the simplest case, imagine a resource `foo` with a to-one relationship `bar` of type `foo`. And with this data:

```auto
foo1:
   bar: foo3

foo2: 
   bar: foo3

foo3:
   bar: null

```

If I get the collection of foos I expect to receive all three:

```auto
{
	"data": [
		{
			"type": "foos",
			"id": "foo1",
			"attributes": …,
			"relationships": …
		},
		{
			"type": "foos",
			"id": "foo2",
			"attributes": …,
			"relationships": …
		},
		{
			"type": "foos",
			"id": "foo3",
			"attributes": …,
			"relationships": …
		}
	]
}

```

And if I include bar (`GET /foos?include=bar`):

```auto
{
	"data": [
		{
			"type": "foos",
			"id": "foo1",
			"attributes": …,
			"relationships": {
				"bar": {
					"data": {"type": "foos", "id": "foos3"}
				}
			}
		},
		{
			"type": "foos",
			"id": "foo2",
			"attributes": …,
			"relationships": {
				"bar": {
					"data": {"type": "foos", "id": "foos3"}
				}
			}
		},
		{
			"type": "foos",
			"id": "foo3",
			"attributes": …,
			"relationships": {
				"bar": {
					"data": null
				}
			}
		}
	]
}

```

This document presumably violates the first rule because because the included resource `foo3` (by way of `bar`) is not in the `included` array. If I put a second copy of `foo3` into included (which seems wrong) then the first rule is satisfied, but the second is violated. And if I put `foo3` into `included`, and remove it from `data` then both rules are satisfied, but it seems to violate my expectations as an API user (and produces some ambiguous semantics in the general case).

I assume the right answer is that included resource really **must** be in either the data or included sections but not both, and that clients are expected to resolve relationship data by searching both `data` and `included`.

Is that correct?

---

<div class="post-metadata">

**Author:** ![maark](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/maark/32/184_2.png) [@maark](https://discuss.jsonapi.org/u/maark)\
**Post date:** [July 24, 2019, 2:59am UTC](https://discuss.jsonapi.org/t/cycles-in-relationships/1649/2 "2019-07-24T02:59:46Z")

</div>

Yes, that is correct.

`foo3` is already included in the compound document and cannot be under the `included` array.

I would interpret “included resources” in the first rule you mentioned as “included resources that need to be added to the document in addition to the primary data”.