PÃ¥l BergstrÃ¶m wrote:
Robert W. wrote:
I replied to a very similar question a day or two ago.
Rails provides namespaced resources for just this sort of need.
See the following reply:
2 RESTful controllers for the same resource - Rails - Ruby-Forum
Thank you. However I still not sure I see the benefit from the old way.
Especially when you have a lot of extra logic and presentations/views. I
mean work-wise it must mean equally much work.
I don’t view the RESTful design as an effort to reduce the amount of
work. It’s not about that at all in my view. Compare it to the benefit
of testing. I think everyone would agree that doing TDD/BDD add more
work up front. It certainly add more lines of code the develop has to
write. What we hope for from testing is that it will make life easier
later and raise our confidence in the code we write.
The benefit is similar with RESTful Rails (at least as I see it). Before
the new RESTful style everyone was just doing their own thing by
defining routes to arbitrary actions with little consistency. The new
way imposes new conventions removing even more decisions about how to
architect an application.
Eliminating decisions sounds like a bad thing to a lot of people. Maybe
that has some merit when there’s just one developer on a project. But,
when you work in a team (or open source) these types of decisions are
bad. Reducing the number of design decisions leads to more maintainable
code, and a more consistent architecture. More consistent architecture
reduces the effort when looking at other people’s code. You begin to
expect certain things in certain places with specific names. This mean
you don’t have to spend time deciphering what the developer means by
“show,” “new,” “create”, etc. These actions are now defined by
People often seem to confuse “convention” with “limitation.” I don’t see
that the RESTful design imposes any limitations on your overall design.
It only imposes conventions for the things that all applications need to
perform like listing, creating, changing, showing and destroying things.
So maybe you don’t see the benefits, possibly because you haven’t given
REST a real chance to grab your imagination, or it just doesn’t fit your
development style. I started off struggling with this idea myself so I
put my mind to work studying to understand why it has merit. I now feel
the freedom of not having the think about these basic design decisions,
so I go on with what makes my application unique and interesting.
Are there any professional rails programmers that doesn’t work with
RESTful design, and if so why?
I’m sure there probably are, but I think the number of them are
shrinking as more developers begin to see the benefits of REST. One
thing that I’m pretty sure about is that RESTful design is here to stay.
I believe all future development of the Rails framework will focus on
making that design style better. I imagine pretty much no effort will be
spent on the “old” style. I don’t think it will be removed from Rails
anytime soon, but the RESTful style has been hugely successful and I
think that’s great.
All this being said, if you’re the architect of your own project then do
things however you want. But, if you ever need to work with a team of
Rails developers you might have a battle on your hands.
I also think that the vast majority of feedback you get from this forum
will encourage the RESTful design style.