In simple cases, some kind of “request attributes X, Y, and Z, get a hash back” on the model works great. What I’ve found is that by allowing each view to decide what data is relevant, I can expose more or less data for each API call, with the intent of reducing the number of followup calls that a developer would have to make in order to get all the data they want, without necessarily bloating the response results by throwing in everything and the kitchen sink.

If I have topics -> posts -> users, and I request a list of a user’s posts in a serialized format, I may want something like:

user {
  id
  name
  picture
  posts {
    post body
    post date
    post link
    owning thread {
      title
      link
    }
  }
}

However, if I want to get a list of posts in a thread, the view may need to be something like:

thread {
  title
  link
  posts {
    post body
    post date
    user {
      id
      name
      picture
    }
  }
}

Two very different views. To do those in the model, I’d need something like

@user.for_serialization(:id, :name, :picture, [:posts => {:body, :date, :link, [:thread => {:title, :link}]}]).to_json

@thread.for_serialization(:title, :link, [:posts => {:body, :date, [:users => {:id, :name, :picture}]}]).to_json

Oof. Starting to get a little heavy, and that’s both assuming a for_serialization that accepts nested attributes like that, and a relatively simple example.

If you want to get more complex and start including data that’s not necessarily available to the model, like, say, links generated via your routing, then you have to start passing procs into your for_serialization. It becomes a giant unholy mess.

I did initially go the route of an ActiveRecord extension which provided super-customizable serialization calls, with nested associations and procs and the like, and it was just incredibly unwieldy to use in practicality.

def public_timeline_attributes
  self.attributes.reject do |attribute, value|
    not %w(id title created_at udated_at).include?(attribute.to_s)
  end
end

Of course, you’d abstract it out to something where you can just name which parameters to expose, and have it always respond with a Hash. This way calling #to_json or #to_yaml on it always gets what you want.

There may be better solutions but I think putting attribute publicity is something that the model should concern itself with, especially when you can keep the view very simple and clean (and not requiring transforming to XML then back again). It makes changes in the model site-wide and maintenance of those views not necessary.

In the MVC architecture, the model should simply present its data to the view, and the view should decide how to present that data to the user; placing ownership of the model’s displayed format in the model’s hands violates MVC, and makes using it somewhat more brittle.

For JSON and YAML, all you need to do is define a method on the model you want to expose, like so:

class Post < ActiveRecord::Base
  def to_json
    self.attributes.to_json
  end
  def to_yaml
    self.attributes.to_yaml
  end
end

Of course, if you want, you define a method like so:

def public_attributes
  self.attributes.reject do |(attribute, value)|
    not %w(user_id, title, body, created_at).include?(attribute.to_s)
  end
end

Then you can have:

def to_json
  self.public_attributes.to_json
end

That means no code in the controller… much cleaner.

Also provides you a little hook to even add computed attributes if you like, or include even a user’s attributes instead of a user ID. Whatever.

Much cleaner in my opinion.

Rails’ baked-in REST support is great. Build your app right, and you can expose a programmatic interface to your users for free….

Here’s what I came up with. Not too surprising.

[chris@polaris benchmark]$ script/runner benchmark.rb
find_by_sql (10000x)
  2.430000   0.580000   3.010000 (  4.457347)
find_by_id (10000x)
  4.520000   0.490000   5.010000 (  6.620790)
find with conditions (10000x)
  3.740000   0.530000   4.270000 (  5.881615)

It would seem that the find_by_id adds missing_method overhead, while the find(:all) should bypass that, and give you something a bit more similar to the find_by_sql.

Thanks.