Friday, May 25, 2007

Auto-Generate REST Boilerplate Code With make_resourceful

One of the big ironies of Rails is that it went from criticizing J2EE for its "XML situps" to creating reams of ugly boilerplate code for its REST implementation.

2005:

2006:

Turns out there's an awesome solution. I skipped this presentation at RailsConf, due to general hype fatigue - I needed a rest from REST - but it turns out I missed something awesome. Check the slides PDF for a way to get all the benefits of REST without any of the ugly repetition.

6 comments:

Ooh, that knocks the stuffing out of acts_as_resource, with the added advantage that I don't have to maintain it.

I wonder how well it plays with my latest (not quite released yet) toy; datestamped_resources, which builds you a resource of the form /resources/:year/:month/:day/:id and fixes up the named route helpers to allow to_param to return an array...

Our very, very earliest solution was to inherit an abstract controller. But, in the long run, we felt that it was easier to keep things clearly wrapped up in the Controller itself and utilizing a DSL for defining the overrides.

The implementation you linked to actually looks pretty good. It would make it easy to override any number of those helpers. Which, is exactly the tactic we took with ours. However, we sort of break ours up into more atomic parts. For instance... what if I like everything that "show" is doing, but I want the response to be different? I have to start from scratch?

Obviously, major changes require re-writing the entire action, but most of the time, we have found there is only one line or so I'd like to add or override about a controller action.

Anyhow, good work on that project (if its yours) and may the best implementation win! ;)

Really the only way to find out is to test them in the field. That being said, it's not necessarily a duel; probably the reason this stuff hasn't been wrapped up into Rails core yet is because it can be more effective when there are multiple solutions, since there are likely to be multiple problems for those solutions to address. REST is sufficiently complex that a one-size-fits-all solution would probably suck, so rather than the best solution winning, we may just see many solutions prosper.