RESTful communication for web applications

In my previous post I rambled about business logic in web-applications. This topic surfaced as during my implementation I came across a problem with delivering aggregated data structures to the client-side of SAW.
An implementation of Backbone.Model encourages CRUD interaction with RESTful server-side interface, and doesn't put constraints on the nature of JSON data delivered. In particular it is happy to receive nested JSON trees. Particularly in my case a representation of the model was enriched with the two lists of elements referenced by and referring to the element in question, roughly as presented on the example bellow:
{

• name: Exercise 3
• id: 4faa69ef924ff86933000001
• type: Project
• related_from: [
  • {
    • _id: 4daff753798e1c6dec000027
    • _type: Taggable
    • created_at: 2011-04-21T09:22:27+00:00
    • name: local bank logging information
    • type: Issue
    • updated_at: 2012-05-10T14:35:40+00:00
    }
  • {
    • _id: 4fb0c54b924ff84e1a000002
    • _type: Taggable
    • created_at: 2012-05-14T08:41:47+00:00
    • name: Banking Interface Adapter location
    • type: Issue
    • updated_at: 2012-05-14T08:41:48+00:00
    }
  • ]
• related_to: [ ]

}

What seemed as a good idea that could save 2-3 HTTP calls ended up in a troubles when synchronizing back the Backbone.Model after applying some changes to it. In fact server-side could have filtered related_to and related_from from the PUT request parameters, but still a substantial amount of non update-related data was traveling back and forth.
Another option would be to interpret PUT/POST of these lists as valid operations of on the related item lists. But this implies implementation of quite some model-related logic into the server-side. I decided against this and added simple, generic routes serving aforementioned lists on separate requests:

(Ruby on Rails 3.1 routes.rb)


[...]
get 'r/:id/related_to' => 'tag#dotag'
get 'r/:id/related_from' => 'tag#untag'

get 'r/:id/related_to/:type' => 'tag#dotag' 
get 'r/:id/related_from/:type' => 'tag#untag'

get 'r/:id/:attribute' => 'r#attribute'
put 'r/:id/:attribute' => 'r#setAttribute'

get 'r/:item_id/dotag' => 'tag#dotag'
get 'r/:item_id/untag' => 'tag#untag'
resources :r
[...]


In general it looks for me like RESTful data access promotes small-atomic data structures with explicit division between read-write resources and read-only aggregations. I would be eager to hear your opinion about it.