Какова польза от разделения relationships и attributes в спецификации JSON API (jsonapi.org)?

Question

[Илья Мясин]

Привет! Думаем, как сделать взаимодействие SPA с бэкендом, смотрим в сторону jsonapi.org - но уже руки тянутся докрутить под себя. Напомню, по спецификации объект ("resource object") должен выглядеть так:

{
  "type": "article",
  "id": "1",
  "attributes": {
    "title": "Rails is Omakase"
  },
  "relationships": {
    "author": {
      "data": { "type": "user", "id": "9" }
      // здесь еще может быть опциональный ключ "links"
    }
  }
}

Борюсь с искушением сделать так:

{
  "type": "article",
  "id": "1",
  "attributes": {
    "title": "Rails is Omakase",
    "author": "9"
  }
}

Потому что я вот только накодил на бэкенде такую сериализацию, а теперь мне надо на JS расколдовать его обратно в плоский объект =)

В клиентском коде уже есть информация о связях, то есть js знает, что article belongs_to author, и что author это user.

Понятно, что вариант из спецификации - более самодокументируемый, но для внутреннего API это, кажется, не так важно.

Еще теряется свойство type, но я сходу не могу придумать, когда нужно заранее знать тип для связи (если их может быть несколько разных в коллекции).

Что я упускаю? Может какие-то готовые инструменты работать не будут? Отговорите меня =)

P.S. А вообще jsonapi норм? Связываться с Graphql пока не хотим.
P.S.-2 На гитхабе есть https://github.com/yury-dymov/json-api-normalizer - но он оставляет ссылки в виде пар "тип-значение", только убирая лишний уровень "data". Есть какая-то польза от хранения их именно в таком виде (у меня Vuex)?