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:
  • nameExercise 3
  • id4faa69ef924ff86933000001
  • typeProject
  • related_from: [
    • {
      • _id4daff753798e1c6dec000027
      • _typeTaggable
      • created_at2011-04-21T09:22:27+00:00
      • namelocal bank logging information
      • typeIssue
      • updated_at2012-05-10T14:35:40+00:00
    • {
      • _id4fb0c54b924ff84e1a000002
      • _typeTaggable
      • created_at2012-05-14T08:41:47+00:00
      • nameBanking Interface Adapter location
      • typeIssue
      • updated_at2012-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.

Business logic in web-oriented application

Software Architecture Warehouse started as a web-based client-server application with major part implemented on the server-side. Ruby on Rails based back-end hosted persistence, business logic, and view generation. Client (web-browser) was merely responsible for rendering server-side generated views. Over time it became clear that this set-up is not capable of fulfilling requirements of highly-interactive collaborative usage.
Today, weight of SAW shifted dramatically towards the client-side. Thanks to application of frameworks such as Backbone or Marionette, user interface rendering moved completely to the client-side. One of the hesitations that I had recently was where to position application business logic.
In fact I find it useful to speak of two kinds of business logic:

  • presentation/view oriented logic - can and should be implemented on the client-side, because this way it offers very good responsiveness (low latency) and thus good user-experience
  • data/process oriented logic - can remain on the server side, because of the data access security and consistency concerns.