As part of my ongoing professional education, I’ve decided to read through several Ruby on Rails projects on Github. It has been a great experience, and I am learning a lot. It’s insightful to see where I’m better than other software architects, and where I have room to grow – there are some very nuanced lessons to learn, and some very simple ones. This is one of the very simple ones.

Since Ruby on Rails introduced automagical RESTful routes, I’ve become stricken with a bad case of RESTful Fever. Maybe you’re familiar with RESTful Fever. It’s where every controller and route must be perfectly RESTful, or you lose sleep at night. Many Rails developers suffer from RESTful Fever.

When I started studying Rails code on Github, I expected to find rolling hills of RESTful conrollers. I expected to walk away embarassed at how RESTful everyone else’s controllers were, and how cobbled mine were.

What I found was the opposite.

Most leading Ruby on Rails projects – like Discourse and Redmine – aren’t married to RESTful routes. They have RESTful controllers, but typically for less prominent, behind-the-scenes functionality. The controllers whose routes are common, public-facing ones (like, say, example.com/signup), are almost never RESTful. Many of these controllers are a hodge-podge of whichever URL the developer wants to route. Of the dozen or so Ruby on Rails Github projects I looked at, none of them had 100% RESTful controllers mapped perfectly with routes; only a few were over 50% RESTful.

What I learned was: it’s okay to make non-RESTful controllers & routes in Rails.