Learning how the rails routes are generated and how they map to HTTP methods and SQL queries is a foundational piece of knowledge that is missed by many developers when starting out. In this post we will explore some of the basics that will help fill in the gap so that students can understand Rails routes in the least amount of time.
Rails convention depict that a controller should only have 7 actions most of the time. Generally speaking if you are creating a controller or defining routes and you feel like you need something other than the 7 standard action you should consider creating a new controller.
In the rails router config/routes.rb
we usually define routes using someting like resources :posts
. This will generate the 7 default actions for us.
posts GET /posts(.:format) posts#index
POST /posts(.:format) posts#create
new_post GET /posts/new(.:format) posts#new
edit_post GET /posts/:id/edit(.:format) posts#edit
post GET /posts/:id(.:format) posts#show
PATCH /posts/:id(.:format) posts#update
PUT /posts/:id(.:format) posts#update
DELETE /posts/:id(.:format) posts#destroy
Let's dissect this further and put it in the context of HTTP methods and SQL queries.
HTTP GET
Let's begin with the most basic HTTP method and that is the get
method. Get is used to do exactly that to get
data from the server. Any time you have to read any kind of data from the server remember that get
is how you should do it. The data format does not matter. Whether you are getting html or json or xml data from your server at the end of the day http get is how you are going to do it. How does this map to Rails routes? Out of the 7 standard action in rails HTTP GET maps to 2 of the actions.
#index action
The index action is use to get
a collection of items. It should also be the action to use if you need to filter or sort through the collection of data. Generally this maps to the SQL SELECT
query, you will be generally selecting data from the database, to render out in your view of some kind. Since you are potentially retrieving 100s of records in one call it is generally improtant to keep the retrieved data simple, just enough to render out the view for the user to select. So maybe you would only render the title, author's name and the published date and maybe a bit of a blurb of the post to give enough context to the user.

Generally we can pass parameters into the url of the GET request to modify how the the database will be queried. We usually see things like the following
https://www.codemy.net/posts?q=rails
In this case the q
is the parameter name and the rails
is the value. This value can be read by the controller and used to modify the database query.
#show action
The show action also uses HTTP GET
to retrieve the data for an individual post. The difference between #index
and #show
is that the show action is retriving only one record. This means that we can load the object in depth. So If our data has deeply nested relationships the #show action would be where we would load the entire data structure for that object including all of the nested objects in the case of a blog, you would load the entire body, the comments the author's detail, and maybe even a 'related post'.

When running rails routes
command we can see the HTTP Method attached to the actions.
posts GET /posts(.:format) posts#index
post GET /posts/:id(.:format) posts#show
So in generaly HTTP GET
maps to #index
and #show
action which maps to SELECT
SQL query. This is pretty much the basis of MVC.
The Controller receives the HTTP GET
request and uses the Model to query the Database with the SELECT
statement and finally sends the response back using the View. If you would like to see a more detailed explanation in a video check out the free episode below.
HTTP POST
The HTTP POST
method is generally used when the user needs to 'post' something to the server. This usually means the data inside the database will be modified in some way. There is no real convention with the HTTP Post some developers use POST to create / modify records in the database, but in Rails and many other frameworks with RESTful conventions POST
usually maps to the #create
action which also means that it maps to the SQL INSERT
statement.
#create action
The create action will not accept query parameters instead any parameter to be processed by the server is passed in the body
of the request. So for example form pameters are usually automagically processed by Rails and is exposed to us as params
in the controller.

We then need to sanitize this parameter to make sure nothing malicious is being passed in using something called 'strong parameters' which is explained further in the member exclusive episode below.
If you run rails routes
and find the HTTP POST method you will see something like this.
POST /posts(.:format) posts#create
Don't confuse the /posts with POST /posts is the path we might as well call the path something like /comments. It's the value we passed in when we defined our routes.
HTTP PUT / PATCH
HTTP PUT / PATCH is also used to create or update records in the database. However the main difference between PUT and POST is that PUT is meant to be idempotent. If you posted a form twice using POST it should create 2 records in the database however in a PUT / PATCH request if you submit the same form twice it should not modify the database a second time. This is what idempotent means. In Rails HTTP PUT
/ PATCH
is mapped to the #update
action, which is usually mapped to the SQL UPDATE
statement.
#update action
The update action in rails will also accept the body
and convert it into params
for us in the controller. We can then pass that parameter through the same sanitization process and pass it into the model for updating our record in the database. There is 1 discernable difference between #create and #update, and that is the #update action requires that a record already exist in the database this is because the update action will usually reference the existing record via some kind of :id

Above you'll see a form that will submit using the PATCH method. Since HTML forms can only submit GET or POST request we need some special help to manipulate the request to be a PUT / PATCH request. Note that the form is pre-filled with the value from the existing record in the database.
<input type='hidden' name='_method' value='patch' />
The line above helps rails know that this request is a PATCH
request and we can also see the action
of the form is submitting to /admin/posts/2
the number 2 in this case will map to the :id
in our rails routes.
In this case we have a route that is under the admin
namespace like so.
PATCH /admin/posts/:id(.:format) admin/posts#update
If you would like to learn more about namespacing you can watch the following free Rails Foundation episode on Namespacing.
HTTP DELETE
The last and final HTTP method the DELETE method is used to DELETE resources from our application. Usually the DELETE
method maps to the #destroy
action in the rails controller which in turns maps to the DELETE
sql statement.
#destroy action
The DELETE
action is alot like the PUT
/ PATCH
http method in the sense that the HTML standard can't make that kind of request. It needs a little help from the framework.

Rails will automatically map this button to the DELETE
request which will invoke the #destroy
action in the rails controller.
View Helpers
We might notice that when we actually invoked rails routes some of the routes have keywords next to them.
posts GET /posts(.:format) posts#index
POST /posts(.:format) posts#create
new_post GET /posts/new(.:format) posts#new
edit_post GET /posts/:id/edit(.:format) posts#edit
post GET /posts/:id(.:format) posts#show
PATCH /posts/:id(.:format) posts#update
PUT /posts/:id(.:format) posts#update
DELETE /posts/:id(.:format) posts#destroy
The first routes have the posts
keyword next to the route output, and you'll notice that the new
, edit
and show
action have some kind of keywords next to them. This is so that we can use the helper method to generate these routes separately. In rails there are 2 main ways to use the helper. For example the new_post
keyword can be used like this.
new_post_path => /posts/new
new_post_url => http://localhost:3000/posts/new
Any time you see the keyword they map to the 2 helper methods with the path or url suffix. The PATCH / PUT , DELETE and POST methods don't have keywords next to them because they use the same one as the one above them. So for example to generate a POST url or path you can use posts_path
and since the form will automatically submit using POST
the server will know to map correctly to the #create
action.
Summing Up
Understanding how Rails routing work can be of immense help in understanding the framework itself. Following the conventions and adhering to the principles set by the Rails framework can help us move faster in our development lifecycle.
We now also see that the order in which the rails routes
command output the routes have a purpose it helps tell us which helper method we should use. So we need to 'read between the lines' a little bit to understand how it all works together 😜.
Some of the episodes mentioned in this post are from the Rails Foundation video series. If you are interested in learning rails or getting a deeper understanding of rails you can enjoy the entire series of 65 episodes for only $9 / month.