# Array of resources ids in attributes

**URL:** <https://discuss.jsonapi.org/t/array-of-resources-ids-in-attributes/1603>\
**Category:** Uncategorized\
**Created:** [June 12, 2019, 7:46am UTC](https://discuss.jsonapi.org/t/array-of-resources-ids-in-attributes/1603 "2019-06-12T07:46:42Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![deividas](https://avatars.discourse-cdn.com/v4/letter/d/e19b73/32.png) [@deividas](https://discuss.jsonapi.org/u/deividas)\
**Post date:** [June 12, 2019, 7:46am UTC](https://discuss.jsonapi.org/t/array-of-resources-ids-in-attributes/1603/1 "2019-06-12T07:46:42Z")

</div>

Hello,

I was wondering, would this approach be valid according the spec:

```
{
  "data": {
    "id": "31168",
    "type": "users",
    "attributes": {
      "name": "John",
      "tags": [1, 2, 3]
    }
  }
}

```

tags array presents a list of resources ids of type `tag`.

This approach would avoid creating another resource ( i.e. user-tags ) since I do not need anything just a list of assigned ids.

---

<div class="post-metadata">

**Author:** ![jelhan](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/jelhan/32/822_2.png) [@jelhan](https://discuss.jsonapi.org/u/jelhan)\
**Post date:** [June 12, 2019, 8:22am UTC](https://discuss.jsonapi.org/t/array-of-resources-ids-in-attributes/1603/2 "2019-06-12T08:22:21Z")

</div>

Spec is quite clear about that one:

> Although has-one foreign keys (e.g. `author_id` ) are often stored internally alongside other information to be represented in a resource object, these keys **SHOULD NOT** appear as attributes.

I don’t see why creating another resource should be required if using resource linkage as intended by spec:

```
{
  "data": {
    "id": "31168",
    "type": "users",
    "attributes": {
      "name": "John"
    }
    "relationships": {
     "tags": {
       "data": [
         { "type": "tags", "id": "1" },
         { "type": "tags", "id": "2" },
         { "type": "tags", "id": "3" }
      ]
    }
  }
}

```

This would also allow usage of related resource links and compound documents, which isn’t supported if you treat a relationship as attribute.