RESTful Routing in Rails
Learn how RESTful routing principles are implemented into the Rails route system to take advantage of standardized naming conventions.
Guide Tasks
  • Read Tutorial
  • Watch Guide Video
Video locked
This video is viewable to users with a Bottega Bootcamp license

In the previous lesson, we had a brief introduction to how routing works in a Rails application. We saw how displays changed in the browser based on our actions. However, that gave us only a partial view on what's going on.

There are multiple ways to understand how routing works in rails. The first way is to go into your config directory and look for a file called routes.rb. In this file, you can see all the routes that your application is using.


This file may look confusing because you only see the projects route, but on the browser you saw different routes. This is because Rails has a neat way of presenting your routes using the resources route helper method, that in turn has seven different routes embedded in it. So, if you are using only the standard RESTful principles, then you can just declare resources projects, and all the seven default routes will be available to your application.

Now, if you want to see all of your routes and not just the word resources, go to your console and type:

rake routes

This command will display all the routes for you, as you can see in the image below:


Let's now analyze what each column means.


The Prefix allows you to use projects as a shortcut inside the application. For example, we can type "projects_path" and this will take us to the paths inside the application.


This is a short-form for HTTP verbs, and it has all the actions inside each one of the routes. If you're not familiar with HTTP, I'll give you a short explanation. The GET verb is used when you're returning a value or values from a database. For example, when you type localhost:3000/projects in the browser, it is a GET action as it is going to retrieve all the records from the database. the verb POST is used when you want to put records into the database. For example, when you create a record, you're putting in data and for this, the POST action gets called.

PATCH and PUT are other HTTP verbs, and if you notice, both of them are mapped to the same controller #update. As the name suggests, PATCH edits the record while PUT puts the updated record into the database. The last verb is DELETE, and this deletes the record.

URI Pattern

This is the link that you would type into the browser if you want to access a function directly. This is also the URL path you can see when you move from one page to another.


The last column is Controller#Action, and as you can see, the controller is projects and this remains the same throughout the list since we only have one controller right now. The action name varies based on the associated methods, so it is #create when you want to create a file and #edit when you want to update something.

If you go to the projects_controller.rb file, you'll notice that all the actions mentioned in this column are a method in this file. Our scaffold created these methods automatically, but when you do it manually, you have to ensure that the mapping is correct. This follows the Convention over Configuration principle that Rails was designed with, which in this case essentially means that the name mapping is very important.


One thing you'll notice in the controller file is that routes get placed as a comment on top of the methods, so this gives you a good idea of how the HTTP verbs are used. For example, you can see in lines 4 and 5, the GET methods. The first method is a call to the database while the second one returns a json value for you, in case you want to build an API.

This has been an introduction to RESTful routing in Rails. I hope this lesson has given you a good idea on how routing takes places in Rails using CRUD and RESTful princples.