Routing in Ruby on Rails

Week 5 of Flatiron School, and we’ve finally graduated to Ruby on Rails. To get here, we’ve learned Ruby, Rack, and Sinatra, before starting to work into Rails — so we know what’s going on under the hood when Rails just does things for you with “rails magic.”

The biggest change from Module 1 (Ruby) to Module 2 (Rails) is that we’re now working with the web browser. To do this, we have to know routing! The routes are how you specify the response to different URLs. This is a little different in Sinatra (where we started learning) and Rails.

In Sinatra, the routes are specified very explicitly, and in the controller for each resource. Below is an example controller from a basic Sinatra app I built. As you can see, each view is rendered explicitly in a given route.

For example, the first route- “ get ‘/songs’ do- defines an instance variable of @songs, which will presumably be used in the view, and then explicitly calls the ‘songs/index’ view to be rendered- so the user will see whatever is written in the index view on their screen. The routes are basically combined with the controller actions.

Ruby on Rails separates routes out from the controller. This confused me a lot at first! Rather than routes being located in the controller, they’re all in the same place, within the ‘config/routes.rb’ file. Rails uses RESTful (Representational State Transfer) conventions extensively for routing, so they’re important to know when creating routes in Rails- I’ll come back to these so don’t worry if you don’t have any idea what that means.

The nice thing about Rails using these conventions so extensively is that as long as you’ve named your files correctly, there are a lot of shortcuts and implicit calling that go on. So, for example, this is a routes file in a basic app:

Rails lets you just call “resources” on the recipe model, and that will give me access to all of the routes without having to manually type them out. This matches up to the below recipe controller (which isn’t fully filled out) — but using just this code, Rails knows what view to display for the basic Create/Read/Update/Destroy(CRUD) URLs.

So much cleaner and easier than Sinatra! As long as you know and follow RESTful conventions, at least…

REST (Representational State Transfer) is a design pattern that standardizes the way we interact with and pass around data on the web. HTTP verbs (‘get,’ ‘post,’ ‘patch,’ etc) are associated with controller actions, which then cause the CRUD actions in the database. Because it’s common and standardized, it makes it nicer for developers to use and manipulate the data.

The 7 RESTful routes above map onto the 4 CRUD Actions, and so the HTTP verbs, the controller action, and the database are all linked together. Rails stresses convention over configuration, so it’s important to use these conventions if you’re going to be a Rails developer.

Although at first I was much more confused by Rails routing than Sinatra, the patterns and specific match-ups of verb-action-CRUD as well as the file specifically for establishing routes has actually made it much more readable and understandable.

You’re also not limited to only using the 7 routes above — not at all! Rails gives you plenty of room to create new routes and play with different patterns, it just would prefer that the baseline routes are standard. While there’s still a lot more to learn about routing in Rails, you now know the basics!

Related posts:

A popular quote by Robert H. Schuller ‘what would you do if you knew you could not fail’ is shared as a way to encourage people to take risks, to try harder, to aspire towards their ultimate dreams…

I have mixed thoughts about what occurred in Charlottesville, Virginia. I know what I am supposed to think. I am supposed to think that racists are suddenly taking over the country, that there is a…

HM Revenues and Customs (HMRC)’s IR35 reform has garnered a lot of criticisms. The Association of Independent Professionals and the Self Employed (IPSE) has advised the government to support the…