Well, Veraticus is right when saying REST is most suioted for applications CRUDing a lot. But thats what most web applications do, especially all the new "Web 2.0" ones. And that's what the main purpose of Rails is (ans was before REST) anyway.
I think what you mean with actions doing different things is actually that the (apparently) same URLS point to different actions, only differenciated by the HTTP Verb that gets send along (GET POST PU DELETE). So /posts/1 can point to an update action or to a delete action.
BUT, and here comes the but, this is - from my POV - nothing to confuse a developer looking at someone elses code. A Developer looks at the code, and wont see the the urls printed out, he sees the helpers. and these are named very transaprently
- new_post_path -> show form for new post
- edit_post_path -> show form for editing a post
- post_path(@post), :method => delete - delete a post.
And those helpers look the same for every resource. I think thats not confusing at all, once you get it.
Plus it adds a tad more security. users can't bookmark/copy/give someone else an url to a create or delete action. that url will, once copied and paste'd - not create or delete, but it wont create an error as well. it will route to the show or index view. where you will most likely find a delete or new link.
And in the controllers, it gets even more easy. There are ALWAYS the SAME 7 actions. If you need less, delete the ones you don'T need. If you need one more in a special situation, add it (and get a nice descriptive helper with it: "publish" action -> publish_post_path(@post).
This is the main and inmportant part of REST. It helps you clean up and seperate your code.
Example: You have a PostsController, with some custom actions for CRUD... no REST. then you want to add comments and think "yyeah, so i add a "add_comment" action to the posts controller!" All fine and dandy.
But then your team partner wants to add comments to the Image Model. So he adds the same code to the ImnageController, but he calls the method "new_comment"
Now you have:
- 2 actions in 2 controllers doing the same thing (not DRY), but with different names. THAT's confusing to me!
With REST, you would create a CommentsController to handle comments for both Posts and Images, keeping your code DRY, and the methods will be the same as in any other controller. "create" will create a comment, just like "create" in the post controller will create a post and so on.
REST for itself is a Design principle to simply write good, selfexplaing code. If the URLS produced by map.resources don't suit your taste, feel free to use the old style. So you can programm REST style without using map.resources. But with it, RESTful development becomes easier as it forces you in the right direction. Adding that "add_comment" action in your PostsController would require you to manipulate the routes file, and when you do it you think "hey, i'm RESTful, should i really be in a situation that requires a non-standard action? No! i need a Comments Controller!"
A RESTful controller is still a normal controller, and url_for(:controller => "posts",:action => "create") will still reach it's target in it. You are not forced to use map.resources nor the REST principles themselves. But it certainly makes your life easier if you build a CRUD app, once you understood the principles behind it...