Rails Routes
When you start learning about the Rails framework and how to set up a Rails project, one of the most crucial concepts to understand is routing.
The Ruby on Rails documentation for routing explains that “the Rails router recognizes URLs and dispatches them to a controller’s action.” What does this mean? Let’s take a look at a common diagram for Rails applications to see if we can break this down a little bit.
When we enter a URL in our browser of choice, we, as the client, are sending an HTTP request and receiving a response from the server.
In a Rails application, these HTTP requests are handled by the Rails Router. Our request (“Hey, please ‘get’ me this website!”) runs through our Rails Router to the correct controller, and eventually, the correct view is delivered based on the controller action and database information as a response (“Sure! Here’s the site you wanted!”).
What are Routes?
Put simply, routes are the code we write that handle the receipt of requests, and then decide what to send back as a response. This code lives in the routes.rb file located in the config folder of a Rails project.
Do you want to visit a web page and see what’s there? You’ll need a route for that. Do you want to post an update to a web page? You’ll need a route for that. Do you want to delete something on a web page? That’s right, you’ll need a route for that. Routes make our Rails apps go.
When setting up our Rails project, it’s important to remember that if our routes.rb file isn’t properly coded, then none of our Models, Views, or Controllers (MVC) will matter, even if they are coded fully and beautifully. You can think of our routes.rb file as the linchpin of the application. Without it, nothing will work.
“I’ve got no routes, so my app is never gonna work” — like the song, right?
The RESTful Routes
A term you’ll come across a lot during your Rails journey is REST. What does REST stand for? Representational State Transfer.
Roy Fielding put forth REST to be a cornerstone of the World Wide Web in 2000 for his dissertation at UC Irvine. Fielding said, “REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability”. This means that we can interact with the web in a way that neatly routes us where we want to go via containing us to specific actions. This idea is a conventional and architectural guideline for defining routes in our apps. With this concept in mind, we can blissfully marry our HTTP routes (GET, POST, PATCH, PUT, DESTROY, etc.) and CRUD actions.
The most basic full CRUD Rails app will need all 7 RESTful routes. Usually, GET requests bring us to a view page, like an index page or a page to create a new record. All the other requests perform some action, but redirect to an existing page.
Here’s how we could code them out in our routes.rb file for a Rails app that tracks baseball players. A GET request to /players will trigger the index action in the players controller, while a POST request to /players triggers the create action. As we can see below, you can also use URL helpers with as: to make easy references to your URL paths. When writing code in the controller actions and view pages, we can redirect or link to show pages with player_path() instead of ‘/players/:id’.
Routing Conventions
Let’s say we had multiple models that we wanted to represent in a Rails app that has full CRUD functionality. We know we’d have to set up our models, views, and controllers (MVC), and of course we know we’d have to code our routes. This means we’d have to set up the 7 RESTful routes for each model in our app. That could get tedious!
Instead, we could use a great Rails tool called resources.
With resources, one line of code gives us all 7 RESTful routes for each model. On top of that, it will also give you access to URL helpers like players_path and new_player_path.
In our case, we want full CRUD functionality, so we’ll keep resources as is, but there’s also an option to limit the routes you want by coding the routes like below. When we call for only :index and :show, we are telling Rails to make us those 2 routes only.
It’s important to note that while resources is a wonderful time-saving tool, it’s wise to avoid using until you’re sure you understand how to write out the routes on your own and what it means to do so for each one. Also, be aware that if you want to add certain functionality, sometimes a custom non-RESTful route is needed that isn’t provided with resources. This is why understanding how to manually code routes is crucial.
Remember
Routes are essential to any Rails app, and requires the developer to understand some basic things about HTTP requests. Get familiar with the RESTful routes, even if you plan to use resources, as they are a foundational piece of architecture in the way we interact with the web.
