RESTful способ работы с двунаправленными отношениями между ресурсами

Предположим, я хотел разработать REST api, который рассказывает о песнях, альбомах и исполнителях (на самом деле я, как и 1312414 человек до меня).

Песенный ресурс всегда связан с альбомом, частью которого он является. И наоборот, ресурс альбома связан со всеми содержащимися в нем песнями. Связи выражаются в представлениях ресурсов посредством ссылок.

Таким образом, представления будут выглядеть примерно так:

{
   song: 'xyz',
   links: [
      { rel: 'album', url: '.../albums/abc' }
   ]
}

{
   album: 'abc',
   links: [
      { rel: 'song', url: '.../songs/xyz' },
      { rel: 'song', url: '...' },
      { rel: 'song', url: '...' },
      { rel: 'song', url: '...' }
   ]
}

Учитывая, что я хочу, чтобы это выполнялось (возможно, проблема заключается в «Данном»), как тогда мне разработать свой API, чтобы создание ресурса альбома или песни не имеет побочных эффектов для ранее существовавших ресурсов песен или альбомов?

Это своего рода проблема с курицей / яйцом.Если я сначала создаю ресурс песни (POST / songs /), а затем создаю ресурс альбома (POST / album /), ресурс песни изменяется как часть создания альбома (что плохо согласно принципам REST), потому что ассоциация между двумя ресурсами обновляется на сервере. То же самое и со сценарием, где я сначала создаю альбом, а потом песню.

Думаю, я мог бы избежать всей проблемы, избегая побочного эффекта на сервере и передав бремя управления двунаправленными отношениями на клиента.

Кроме того, я не хочу, чтобы альбом и песни создавались атомарно как единое целое.

Единственное, что я могу сейчас придумать, - это включить вышеупомянутый побочный эффект в семантику моего API, ответив на создание ресурса представлением, которое содержит список ссылок на ресурсы, которые были изменены в результате запроса. Это делает побочный эффект явным, но все же не успокаивающим.