I think the most important takeaway from this is how malleable and extendable Ember Data and its RESTAdapter are. It doesn't always (or, to be honest, almost never) works out of the box, but it's very easy to tweak.<p>Anyways, as for the way you're handling relationships:<p>The RESTAdapter works like it does because it expects hasMany<->belongsTo relationships. In that relationship:<p>- It can load the child record from an array of IDs on the parent.<p>- When a child record is updated, it is saved back to the server without including the parent.<p>- When a child record is added, it only saves itself back to the server. The <i>server</i> is expected to handle adding that record to the parent resource.<p>- Similarly, when a child record is deleted, it is saved back to the server and the <i>server</i> should remove it from the parent resource.<p>Essentially, the client shouldn't need to save the list of children back to the server.<p>The downside of this is that this doesn't actually work in a hasMany<->hasMany relationship, because a record in that relationship <i>does</i> need to send back the list of resources - it's the same as the way a belongsTo record will include its parent.<p>Regardless, there's no obvious harm in overriding RESTAdapter to do this, and it shouldn't impact the way that a regular hasMany<->belongsTo relationship is handled. Just make sure that the client-side records always have a current representation of their relationships, or you might end up saving back incorrect versions of the records.