021 RR REST Done Right with Steve Klabnik

just wanted to note that this episode's (awesome) picks are not in the "picks" section. It seems that you got something wrong in the numbering of this section.

Excellent discussion! When i was really into unveiling REST, i once found an excellent article that really cleared things up and is well paired with the topics discussed here. I highly recommend it: http://www.infoq.com/articles/webber-rest-workflow Keep up the good work guys! :)

awesome, keep it up :)

I have not found a more enjoyable and informative reference on REST than Jim Webber's REST In Practice (http://www.amazon.com/REST-Practice-Hypermedia-Systems-Architecture/dp/0596805829). He also gives a great presentation on a related topic: http://vimeo.com/17156605

I really enjoyed this episode and hope for another episode or two on the same topic. In particular, I would like to hear more on the benefits and liabilities of REST architecture. There is a lot of talk about is this or that RESTful or not, but little about why do REST in the first place. I'm especially interested in the conflict between OO-style and RESTful style. One of the Rogues mentioned in last weeks episode on Rails and 00 that Rails seems to have just *handled* the object-relational impedance mismatch by pushing the relational side all the way to the URLs. The Rails flavor of REST in particular does seem to lend itself to a anemic domain model. The article Steve mentioned "Execution in the Kingdom of Nouns" really rings true. Sure we can build our web apps by nounifying everything, but what do we gain? When does it make sense to use a RESTful architecture and when doesn't it? The happy medium I've been gravitating to is somewhere around level 2 on the Richardson Maturity Model [1]. Expose objects with a unique URL per object, but expose more methods of the domain model than typical Rails CRUD. For example, given a reservations system, the domain model probably includes Reservation#cancel. I would use a cancel method on the reservations controller instead of adding a ReservationCancellation resource unless the underlying domain model really needed that concept. So to sum it up, how far is far enough with REST [2], and what are the benefits and liabilities of this model of application architecture? [1] http://martinfowler.com/articles/richardsonMaturityModel.html [2] http://www.therailsway.com/2009/6/22/taking-things-too-far-rest