Intro to Routes — the Gatekeepers of your Rails app

So if you had read my previous blogpost, you would have created your app, your database, and established your controllers and models with corresponding attributes. Now we need a way to communicate with the Internet with our website. This is where routes come into play.

Routes are the base for making your app RESTful. REST stands for “Representational state transfer” which is one way of providing interoperability between computer systems on the Internet. Routes will take url requests, direct them to the appropriate controller within your app, and have the controller execute the methods.

The Routing System is the conduit between the Internet and your controllers.

The page to generate the routes can be accessed in your app through the Sublime program. Just open the config folder within your app and click on “routes.rb” Now with the contacts-app from the previous post, there are seven routes that we need to successfully allow the Internet to send url requests. Here is what they look like on the “routes.rb” page:

Rails.application.routes.draw do
  get "/contacts", to: "contacts#index"
get "/contacts/new", to: "contacts#new"
post "/contacts", to: "contacts#create"
get "/contacts/:id", to: "contacts#show"
get "contacts/:id/edit", to: "contacts#edit"
patch "/contacts/:id", to: "contacts#update"
delete "/contacts/:id", to: "contacts#destroy"
end

Let’s explain each route starting with:

get "/contacts", to: "contacts#index"

The command “get” is one of the HTTP verbs. HTTP verbs tell the server what to do with the data identified by the URL. It instructs the server to transit data identified by the url (in this case, “/contacts”) to the client. The “to: “contacts#index” is the controller action and references the controller that the route should activate. In this case, the index method from the contacts controller would be executed.

Many of these controller methods have corresponding “views” pages which is what the user actually sees. For the sake of brevity, I will limit this blogpost to only the relationship between the routes and the controllers with one exception — the “_form.html.erb” which serves a crucial role in having certain routes function seamlessly.

One thing to note is that the HTTP verb “get” allows the user to “read” the information only (of course, links can be placed within the view page to redirect the user to other pages with other routes). This is the “Read” operation in the programming acronym “CRUD” — (Create, Read, Update, & Delete) — a useful reference to the possible operations in any app.


get "/contacts/new", to: "contacts#new"

This route activates the new method which shows the newest contact that was just created.


post "/contacts", to: "contacts#create"

The command “post” is the HTTP verb associated with creating new items, hence the “Create” operation in “CRUD.” The create method allows the user to generate a new person with all their relevant information.


get "/contacts/:id", to: "contacts#show"

Another “get” command that allows the user to read the page of a specific contact based off that contact’s id. When a new user is created, they are automatically assigned a contact_id as an integer. That integer replaces the “:id”. For instance,

http://localhost:3000/contacts/3

would activate the show method which would summon the contact with the contact_id of “3”.


get "contacts/:id/edit", to: "contacts#edit"

This route activates the edit method which presents the contact’s information. Note — this information can be read which is why it has the “get” verb. The reason why the user can manipulate the contact’s information is because in the edit view page we have:

<%= render "form", header: "Edit Contact", url: "/contacts/#{@contact.id}", method_variable: :patch %>

The method_variable “patch” matches the HTTP verb of the next route — the Update route. Also important to note is that this very important line of code renders a very specific views page called “_form.html.erb”

<%= form_tag url, method: method_variable do %>
<div>
First Name:
<input type="text" name="first_name" value="<%= @contact.first_name %>">
</div>
<div>
Middle Name:
<input type="text" name="middle_name" value="<%= @contact.middle_name %>">
</div>
<div>
Last Name:
<input type="text" name="last_name" value="<%= @contact.last_name %>">
</div>
<div>
Email:
<input type="text" name="email" value="<%= @contact.email %>">
</div>
<div>
Phone Number:
<input type="text" name="phone_number" value="<%= @contact.phone_number %>">
</div>
<div>
Address:
<input type="text" name="input_address" value="<%= @contact.get_address %>">
</div>
<div>
<input type="submit" name="Save contact!">
</div>
<% end %>

It’s not my intention to run off on a tangent by showing view pages but this form has a very specific attribute called “value” which will be critical working in conjunction with the next route — the Update route.


patch "/contacts/:id", to: "contacts#update"

The “patch” command activates the update method which takes the existing information of the contact_id and allows the user to input new parameters which would replace the currently set parameters. It’s absolutely vital that your “_form.html.erb” has the value set at “<% value=@contact.whatever-your-attribute-is %>”. Without it, your edit page would erase any parameter left blank. So if we inputted an update to a contact’s phone number without the “value” attribute, that contact’s information would be purged except for the new phone number because your edit page would think you were passing “nil” as the new parameter. This route is, not shockingly, the “Update” operation from “CRUD”.


delete "/contacts/:id", to: "contacts#destroy"

The final route contains the “delete” HTTP verb which is also the “Delete” operation from “CRUD”. A very self-explanatory route, it activates the destroy method which eliminates all data associated with the resource (a specific contact identified by the “:id”, in this case). Once the information is purged, the method usually redirects the user to the index page.


Rails apps have multiple lists of these seven routes that correspond to the different controllers that were initially generated. Notice that in this particular contacts-app not all seven routes are written out:

#contacts routes
get "/contacts", to: "contacts#index"
get "/contacts/new", to: "contacts#new"
post "/contacts", to: "contacts#create"
get "/contacts/:id", to: "contacts#show"
get "contacts/:id/edit", to: "contacts#edit"
patch "/contacts/:id", to: "contacts#update"
delete "/contacts/:id", to: "contacts#destroy"
#users routes
get "/signup", to: "users#new"
post "/users", to: "users#create"
#sessions routes
get "/login", to: "sessions#new"
post "/login", to: "sessions#create"
get "/logout", to: "sessions#destroy"

Different controllers serve different functions and it’s best not to create unnecessary routes as that would violate the DRY ethos of Rails — Don’t Repeat Yourself. DRY is the governing philosophy of Rails. More on that next time!

Like what you read? Give Michael Yatco a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.