Why CRUD and REST is important
For a long time, I didn’t get what the big deal is about pretty URLs like
http://www.example.com/people/1
I still don’t completely get it, but Roy Fielding, who is one of the authors of the original HTTP specification, defined REST in his PhD thesis at the University of Irvine in 2000. Roy Fielding’s dissertation
David Heinemeier Hansson, the creator of Ruby on Rails, says he didn’t get it either for a long time until he actually started using it. His talk at RailsConf 2006 explains why pretty URLs are not just pretty URLs. After listing to his talk, I started to want to learn more about the REST architectural style.
1. CRUD (create read update delete) is a design philosophy. If you find that your application code is getting complicated, you’re probably not done modeling. Your controllers, for the most part, should only have 7 actions: index, new, create, show, edit, update, and destroy. Don’t just model the nouns as classes. When you start modeling the relationships between the nouns like “subscriptions” and “memberships,” DHH claims that your controllers will start looking like CRUD, and your code will no longer be handling exotic exceptional cases and complicated business rules. If your controllers don’t look like CRUD, it means that you’re not done: you haven’t finished thinking about your model deeply enough. DHH reminds us not to forget to model (make classes for) things like relations, events, and states.
2. One of the beneficial side-effects when using ActiveResource (the Rails library supporting CRUD) is that you can use one controller for many clients and get web services, RJS, and mobile phone formats with little or no extra programming.
3. Another good side-effect is discoverability. If everybody followed this convention it would be very easy, if not automatic, to discover web services and APIs simply by knowing the name of the thing that you’re looking for. People can start using your web service to make more interesting applications that combine different web services. It’s kind of like how a UNIX script calls many stateless little programs and strings them together to do something really cool.
David Heinemeier Hansson’s talk
Download the Power Point slides as a PDF file here.
For me, the bottom-line is less code by following conventions. But, I think the point of REST is much more than that. By following this convention and accepting the constraints that REST puts on the way you create and design your applications, not only do you write less code, but you get emergent properties induced by these constraints.
(Slide 23 of Roy Fielding’s RailsConf Europe talk)
I think some of these emergent properties include, 1. layeredness and serendipity (people can create cool stuff from your data if you expose it to them), 2. simplicity (1 URI per model exposed as XML …. that’s pretty simple.), 3. scalability, 4. cacheability, 5. discoverability, 6. reliability.
Fielding’s dissertation takes a couple of cups of coffee to finish, so here are some nice REST tutorials for the rest of us.
There’s a lot to be said about REST, so it’s best you check out the original thesis and some of the many tutorials referenced here. Good luck on your path to coming to peace with REST. As for me, I’m going to start writing RESTful rails apps and see where it takes me. . . . .
Posted by David Beckwith on Oct 28, 2007