REST is a nice theoretical concept and Rails is pushing hard in this direction. We all heard about RESTful Rails and map.resources but at least in my surrounding its adoption is still lacking.
At the last Berlin Ruby User Group meeting somebody asked if one of us had a running RESTful application and only one out of 40 responded. Then we got into the whole 'what is REST, when is your application RESTful, and is the edit-view part of REST...' discussion.
Yes, it would be wonderful if the world would be full of REST Web Services instead of SOAP Web Services but in the end we are talking about Web Services. If your application does not expose a service, there is no need for hardcore REST. That's why nobody raised their hand, nobody had a service to expose. Not yet, you could argue. And by doing it the RESTful way they would prepare for the day that their application is so successful that they start to think about exposing some resources. In in this case they would be prepared. Just add some responds_to magic and boom, you got your Web Service.
And I answer YAGNI. Do it when you need it, too much preparation is evil.
At the moment some people (especially in the Rails community) see REST as the new Golden Hammer. Just hammer with it once or twice on your application and boom out comes a Web Service for virtually no effort at all. And this is what scares me. Don't get me wrong. I like the idea of REST and definitely prefer it to the WS-* way of doing things. But making your application a Web Service that will serve anything, from JSON to XHTML and XML, just because you can will not solve your problems. It will create new ones because you couple different views and interaction schemes.
Seeing DHH at the RailsConf Europe keynote hacking custom MIME types in order to render a different view for the iPhone didn't make me jump up and down in a jolly manner. It made me thinking if the Rails community pushed too hard to the RESTful side. The iPhone required it's own view because although running a stock Browser it has a different interaction scheme. A different interaction scheme should force you to have a different logic in the controller. The responds_to blocks start to grow in complexity and size.
This is the point where you should apply the idea of de-coupling, the idea of services. Let the iPhone have it's own Web Application. Let than this new application access the common resources that the Desktop Browser application and the iPhone application share. This access can be done through just loading the same models through svn:externals or through a REST Web Service.
The REST concept should de-couple different clients (controller and views) from each other and from and back-end code (models).
Sometimes the responds_to stuff makes sense. If you mostly expose data, then offering JSON and XML besides XHTML makes sense if by doing this you save your clients the transformation or expose the data to more clients that you could not reach before. But it you have a Web Application with a lot of interaction then coupling the Desktop Browser version with the iPhone version, the mobile version, the JSON version, and the XML version does not make any sense to me.
For me REST is about exposing interconnected resources through a unified interface. And yes you should let the client choose the representation. But different clients will handle and interact differently with the resources. So please think before reaching for your Golden Hammer.
REST is more than just Web Services or serving different kind of data. Is a way to structure your problems.
If your situation don’t map inside the 7 actions schema, could be extended. That will create a exception to the “REST”, but will be your API signature (if you want to interact with the system remotely).
Also, following a REST model let you reuse and get patterns from your code, like the make_resourceful stuff or reuse Controller Specs (rspec—shared behaviors).
Is more than just “hey, I could render something specially for the iphone”...
Maybe smart rendering should be address for Rails 2.0 (if no #render was specified, use :format and default builders to get actions rendered.
Also, the respond_to is getting to abused. Big chunks of code shouldn’t sit there.
Just my toughts ;-)
Have you actually used the Rails REST stuff?
It’s not just for exposing a REST web service. For me, it cuts my “normal” app dev time by a lot simply because it handles the nesting of resources, and if I use something like make_resourceful, my controllers go from 100+ lines at least to about 5, with the option to add extra logic if I need to.
As for your suggestion that it’s too much preparation, you’ll spend a lot of less time doing map.resources and using logically named routes like users_path rather than something like url_for(:controller => ‘users’, :action => ‘index’) (and if you usually create those routes manually, then you’re still saving time). You don’t have to do a respond_to block; it will automatically assume you want HTML (or other request types; I’m not sure if it does that). respond_to is basically used to restrict which formats are accepted (e.g., if a client requests XML and we don’t play that game, then it returns bad requests errors).
Like I said, the main thrust of REST is the easy web service stuff, but it also help with non-web service development. Tag on the fact that you can make degrading from JavaScript easier, and you’ve got a powerful tool.
I didn’t see the benefit either until I used it on a real application, and if you haven’t yet, then I invite you to use it on something non-trivial. You’ll appreciate it a lot more.
Nice post. REST is one of those things.. hyped a ton, but when it comes down to it, end-users could care less. Sure, if it’s easier to do it and get the same result, great.. if not though, and you don’t need to look at your data in different formats, you’re doing extra work.
That said, since DHH has so “embraced” the concept, doing it in Rails is pretty damn easy.
+1 and raising my hand to Jeremy’s comment, I was skeptical of REST at first and now I’m a solid convert, there’s no cost to developing REST except learning the convention and applying some brain power to how you want to structure your resources. You have to do this with REST or without it so you are not doing any extra work. The benefits are beyond whether you are exposing an api or not, a restful rails app will generally lead to having thinner controllers and a richer domain model that is the result of thinking in resources. Letting the iphone have it’s own application may in fact be the right thing to do for a particular case, but focusing in on this one aspect artificially narrows a discussion of rails and REST, and there’s a whole lot more worth exploring, imo…
I agree that in Rails developing REST is very easy and can save you some time. I’m not arguing against the URL helpers and resource modeling in routes.rb. This stuff is defenitly time saving. What I’m arguing against is that because it is so easy it is temping to overuse it. The Rails REST stuff is also great for plain HTML applications but you should be careful about having to much logic to satisfy different clients.
@Tim: and no +1 for my comment then? :-P
REST is for Application Structure what MVC is for Interaction Concepts.
As said, maybe the iPhone wasn’t the best example of REST by itself.
This post is a good example, not of the problems of REST, but of why REST hasn’t been adopted as widely as it should. It’s not about the services (while that is a nice benefit). It’s a paradigm shift in how you look at an application. It’s about treating it as a bunch of resources. This leads to controllers which are much simpler and consistent.
I agree with the YAGNI approach. Very few of my controller actions have a respond_to block in my RESTful applications simply because it’s not required for the app. Mike Clark posted about this which I encourage you to read.
@Ryan:
I completely agree with Mike Clarks posts and the idea of treating your application as a collection of resources. What I don’t agree with is the growing complexity in the responds_to blocks and the idea of handling all representations and interactions inside a single client app.
In my point of view the modeling stuff (map.resources, unified access through HTTP verbs, etc) should not be too tightly coupled with the idea of serving many different clients with different needs from the same application / controller.
Maybe the title of the post was wrong, it should be more along the lines of
“do not get carried away with putting everything into responds_to and server many different client just because it is so easy with RESTful Rails”
REST is a wunderful idea but as with all wonderful ideas it is tempting to try to fit the problem to the solution and not the other way round.