Topic: REST just seems like a mistake to me.

Yeah, it's a bit of a troll post, but I just really, really don't get the hype behind REST and why RoR went so heavily in this direction.

It seems to me that REST, in theory, seems like a good idea, but in practice it just ends up creating spaghetti in your head.  In situation 1, action B does foo, but in situation 2, action B does bar, in situation 3, action B does foobar.  Anyone trying to maintain your code after the fact, including yourself, has to go through and try to figure out what each situation does and somehow hold that in their head long enough to accomplish whatever it is they need to do.

Maybe I'm just too simple, but this seems like one of those times where trying to be overly clever just creates a bunch of confusion.  I like the action A does A and action B does B methodology. It just makes sense.  Yeah, maybe you have a bit more code to maintain, but it's EASIER to do so, isn't it?

Explain to me why I'm wrong and maybe I can get over being so annoyed that all the new plugins are "RESTful".  blech.

Re: REST just seems like a mistake to me.

You can always ignore REST in your applications. While it's a perfectly usable tool, Rails works fine without it. In fact, REST is only really useful in certain situations, namely when your application is set up to do a lot of CRUDing on your database. If you have an application that doesn't do that a lot, or does many non-standard CRUD transactions, then it'll probably just needlessly complicate your life to use REST.

You do seem to be misunderstanding REST a little bit, though. Actions never do multiple things in REST. Calling the Edit action always shows a page where you can edit an object, whereas calling Update always should update an already-existing object. There's never an action that does multiple things, like edit if it's a get and update if it's a post: in fact, SOAP is much more guilty of this action overloading than REST. Think of how many times you've had an Edit action that has a request.get? or a in it, to handle rendering the edit page and then updating the object once the form posts. REST makes these divisions more logically clear by separating the get and post into different actions.

In the end, REST just lets you use routes more gracefully. So, instead of post/show/1, you use post/1 with a GET method. Both connect to the Show action on the Post controller (and will show the post with ID 1). Then if you want to update that post, you would either post to post/update/1 or put to post/1.

Rails helps take care of generating routes with named routing, too, so you don't even have to remember what method does what, or which URL you're looking for. Just use edit_post_url(@post) and you're done.

Anyway, REST is a cute convenience that makes some applications a lot easier.

Re: REST just seems like a mistake to me.

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...

Re: REST just seems like a mistake to me.

I didn't use to understand what was REST, now I only see websites as rest, and I get mad when websites don't comply to rest principles.

I have run through websites, that used POST to display sorted information, that is just so wrong to me.