What's On Your RADAR?
(Thu Mar 29, 2007) [/Rails] #
If you're still a bit confused about all this REST stuff in Rails, Dave Thomas just posted a great overview of how we got to where we are, and perhaps where we'll end up. And don't feel bad if you're not up to speed on what it means to build RESTful Rails apps. In truth, we're all still learning what that means, and I suspect we have a long way to go.
I've enjoyed the conventions that fall out of the REST style of design. Things like the named routes and the Simply Helpful plugin tend to give an application a good consistent feel to it. Converting my traditional Rails apps to the REST style has largely been an exercise in removing code, and refactoring for the better what's left.
It's worth point out though that you don't have to use the respond_to stanza to get these benefits. I'll take it a step further: Unless you plan to support non-HTML clients in the near future, and you understand their needs, then I'd recommend not using respond_to. It works perfectly well, but it feels speculative to include respond_to stanzas such as this one in all my controller actions:
def show
@event = Event.find(params[:id])
respond_to do |format|
format.html # show.rhtml
format.xml { render :xml => @event.to_xml }
end
end
Until I need to expose events as XML, I prefer to keep things simple:
def show @event = Event.find(params[:id]) end
But, you say, isn't the respond_to block a small price to pay for future extensibility? And the scaffold_resource generator creates it for you anyway. So why not just leave it in? Simply put, it's code I don't need right now. And if it's not carrying its weight in my application today, then I prefer to remove it rather than work around it. If tomorrow I need to create an ActiveResource client for a particular set of resources, I'll add respond_to blocks in for those resources. At that time I'll probably also have a better understanding of what goes in those blocks.
All this to say, you don't have to use all the REST features of Rails to take advantage of the design conventions. At the same time, don't ignore what's going on with REST and Rails because you'll likely miss out on lots of good stuff to come.
