Sean Colquhoun wrote:
Can anyone explain the benefits of RESTful design so that a
non-programmer will understand? I can't for the life of me understand
why I would want to go through all the trouble of limiting myself to
seven methods per controller or typing in arcane exceptions if I want to
use an eighth or ninth or tenth. It just seems to make more sense to
keep everything in one simple file.
Actually the 7 methods per controller is a Rails implementation detail. There's nothing about REST in general that prescribes this distinction. Actually there's nothing about REST that says you even have to use controllers. What REST does say is that you should model your application with a couple of things in mind. Off the top of my head I can think of:
- Everything is a resource, so every URL should point to some "physical" entity. This means there's no "action" URL's like "subscribe" or "delete".
- The actions are moved to the HTTP methods GET, POST, PUT and DELETE (there's a few more, but they're not interesting in this discussion). So you're limited to modelling your application with these actions.
- The client should track it's own state. This means every request to the server can be handled in total isolation from everything else.
- GET requests must never alter the state of the application. No destructive or constructive GET requests.
- GET and PUT are idempotent, doing it once yields the same result as doing it multiple times.
What this means if that REST prescribes a way of thinking about and designing web applications. I think I read the expression "A straight jacket for your mind" somewhere. You may compare it to the opinionated ways of Rails, where model classes should be in this folder, the extension of your view file determines which renderer should render it, database tables must be pluralized, etc. So in the same way as Rails gives you a set of conventions to abide by in your code, REST gives you a set of conventions to abide by in the way you design your application from the users point of view, that is what entry points does the user have into the application and how is the user supposed to interact with the application. And this is probably the biggest reason why you would want to do REST. To have a set of conventions to guide you in your design, just like Rails guides you in your implementation.