Question

In the process of making an ebook, users have to edit its content, edit its metadata, choose marketing options, (such as pricing and distribution) and publish.

I started to put each everything inside the Book resource (contents, metadata, marketing options etc)

Then each step of the process (contents, metadata, marketing) is an action inside BooksController.

But Books started to grow a lot in terms of attributes and actions.

I’m wondering if it is better to force RESTfulness by creating singleton resources, each associated to their respective book.

The routes would be:

• /book/12/content/edit
• /book/12/metadata/edit
• /book/12/marketing/edit

This seems more elegant, as each of these “resources” are RESTful and have few attributes each. But the resources are not objects (Marketings?).

Do you thing it’s OK to create meaningless resources just to be RESTful and keep code in order?

Is there a better way to group similar attributes than create resources out of them? Thanks.

Answer 1

I’m porting a large PHP application to Rails and we have a fair few “ad-hoc”resources, such as admins have the ability to log in as another user with their permission, in order to correct issues etc. I would always complain that features such as logging in as other users should not be bundled into a huge monolithic AdminController as actions loginAsUser and logOutOfUserAccount. In our Rails app we try to visualize as much as we can in terms of resources, so using the example I just gave, we have an Admin namespace, under which there is a UsersController (/admin/users/:id) and as a sub-resource of users, we have a UserOverride resource (/admin/users/:user_id/override)… it feels really logical that we just POST and DELETE to this resource.

So getting back to your example, yes, I think you should break those sections down into separate resources. It certainly seems like BookContent should be a sub-resource of Book, and MarketingOptions too.

resources :books do
  resource :content
  resources :marketing_options
end

etc

This is both nicer to work with (more modular) and easier to visualize just from looking at the routes alone. You also get the benefit of really predictable path helpers:

<%= link_to("Marketing Options", book_marketing_options_path(@book)) %>

You can’t try to force every conceivable route into a RESTful resource ideology though… if it feels like it’s forced, then it probably is.

There’s a decent blog post I wanted to link to that (despite some poor grammar) actually does a pretty good job of showing you how to think about your application in terms of resources… I can’t find it though. I’ll add a comment if/when I do.

EDIT | Just re-reading your original question and wanted to clarify: resource != row in database. A resource is anything you can conceive as a “thing”… I know that’s a very broad statement, but just like an Object in OOP doesn’t have to represent something concrete/material, nor does a resource in a RESTful design.