title: RESTful way of dealing with bi-directional relationships between resources
body: <p>Let's suppose I wanted to design a REST api which talks about songs, albums and artists (actually I do, like 1312414 people before me).</p>
  
  <p>A song resource always is associated with the album it is part of. Conversely, the album resource is associated with all songs it contains. The associations are expressed in the resource representations by way of links.</p>
  
  <p>As such, the representations would look something like this:</p>
  
  <pre><code>{
     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: '...' }
     ]
  }
  </code></pre>
  
  <p>Given, that I want this to hold true (maybe the problem lies in the "Given"), how then do I design my API, such that the creation of an album or song resource does not have side effects on previously existing song or album resources?</p>
  
  <p>This is some kind of a chicken/egg problem. If I create a song resource first (POST /songs/) and then create an album resource (POST /albums/), the song resource gets modified as part of the album creation (which is bad according to REST principles), because the association between the two resources is being updated on the server. Likewise for the the scenario where I create the album first, the song second. </p>
  
  <p>I guess I could avoid the whole issue by avoiding the side effect on the server and passing the burden of managing the bi-directional relationships to the client.</p>
  
  <p>Also, I don't want album and songs to be created atomically as a whole.</p>
  
  <p>The only thing I can think of right now, is to include the aforementioned side effect in the semantics of my API by responding to a resource creation with a representation which contains a list of links to resources which have been modified as a result of the request. That makes the side effect explicit, but still not restful though.</p>