Rails RESTful Routing Convention Decision: To Keep Or To Break?
Almost as with everything else in life, decisions on rails convention with respect to routing come with benefits and consequences. In this article, we are going to look at some pros and cons of keeping conventions and breaking them. The idea is to create some sort of decision making aid for those beginning with Ruby on Rails when it comes to routing. From the foregoing, it is clear we need to define what those conventions we are looking to keep or break are.

.
“The sower may mistake and sow his peas crookedly: the peas make no mistake, but come up and show his line.” ~Ralph Waldo Emerson
“Nobody ever did, or ever will, escape the consequences of his choices” ~ Alfred A. Montapert
.
Rails Routing Conventions
Ideally, it goes this way for displaying individual items;
- An incoming request is made
GET /sushis/122. The application asks the router to match the request to a controller action. The first matching route if RESTful conventions were followed would be;
get ‘/sushis/:id’, to: ‘sushis#show’This would be the sushi controller using the show action/method to show details of the sushi whose ID is 12. We might have either rendered or redirected as the need calls for. The details shown depend on what we set up the show page to display.
RESTful
The acceptable convention is that all routes are RESTFull. It is the default routing convention applied when we use rails generators. A sushi#show controller will render to a show view page unless it is redirected to a different page. This makes for a straightforward development strategy. Running “rake routes” will show what routes are available and the default helpers that come with them.
Named Routes
You can name routes using the :as parameter when defining the routes in routes.rb. eg
get ‘sushi’, to: ‘sushis#show’, as: ‘sushi’This will provide you with sushi_url and sushi_path helpers that you can literally copy and paste in your application where needed.
These rules also apply
- View file names should match the controller and action they are intended to render.
- Route names need to be snake-case, and usually would match the controller. Usually, if the route is plural, it uses plural “resources”, else it is in the singular.
- File trees are consistent. Controllers are in the app#controllers folder, views in the ‘views’ folder, etc.
- All routes are located in config/routes.rb
- Ordering of the routes matter.
Naming conventions (including other aspects of rails other than routes) pretty much follow the diagram below.

Keeping Rails Routing Conventions
Benefits
- Makes it easier for a fellow developer who would have to deal with your codes when you leave your organization
- Frees the developer up to focus on creating meaningful capabilities for the app, improving productivity.
- Makes it easier to learn for beginners.
- Keeps the original intent of rails, which basically means keeping programmers happy.
- Keeps routing feeling a bit more ‘natural’. If you have folder with just an orange, it will be weird to call it ‘oranges’ folder. This sort of concept translates well with rails routing naming conventions, eg when using resource generators.
Challenges Created
- Tends to make applications seem like cookie cutter
- Easy to guess routes, potentially creating security issues that even beginners can exploit.
Breaking Rails Routing Conventions
Benefits
- Clearly, it weeds out a large chunk of bad guys being that most just have basic knowledge. If someone that can figure out routes with conventions broken attacks, it is fair to say Houston has got a problem. The idea is to make bad guys put in the work at least.
- It lends lots of help in the development of custom applications.
- It enables developers to tweak the application to their taste
- Proves you are badass when you take it all the way to writing gems to hack the process
Challenges Created
- It could be an overkill where what is needed is a simple application.
- It could be hard to debug but a third party.
- From the point above, it also means getting help with bugs could be a problem as only you know what you did.
- Newer versions of rails might change certain conventions and something will snap in your application.
- Documentations may not help a lot or hard to track down when you run into issues.
Popular Opinions
As with anything called opinion, there are tons of it on rails convention vs configuration(breaking convention) argument. It all depends on who you ask. Teachers who have to go over a large number of student codes (hiring managers, wink wink), rails beginners, experienced developers and the larger group of ‘regular programming folks’ out there favor convention; it makes life simpler for everyone. If it ain’t broken, why fix it?
On the other side of the fence is the real geeks and nerds, usually (but not all) the kind that writes forty thousand lines of code to make a microwave work. To these folk, popping your pizza in the oven, setting a timer and eating your pizza few minutes afterwards is too elementary. Why not slap on a clock on that thing and make it possible to connect to your home wifi while at it. How about making it possible to see the inside of your microwave at home from your office? Among these folks are also the experts trying to take us to another galaxy, or some secretive government project. Area 51 anyone? These folks lean heavily into configuration due to pride or necessity.
Bye and large, it comes down to what this dog is saying;

Personal Perspective From Experience
As apparent as it seems that I was going in on the second group on the opinions side, (and I really was), I found myself behaving like them whenever I tried making anything not ‘usual’ in rails. The moment the products of ‘rails generate new’ will not get the job, it down the slippery slope of breaking conventions. Simply put, if it a simple project, keep conventions. If not, you have got a decision to make.

