RESTing with Routes on Rails

It's been a rather quick trip running through Ruby and introducing the Rails framework into our repertoire during my five weeks at the Flatiron School's Brooklyn campus. I've learned to appreciate every bit of code I've encountered and the accompanying thought processes. Rails continues to impress with its layers of abstraction that are at our disposal. In particular, the addition of routes as we've moved from Sinatra to Rails has been a challenging and interesting concept to grasp. When talking about routes, it's also crucial to discuss RESTful standards.

One can think of routes as the map connecting HTTP Verbs and URL paths to the appropriate controller and a controller action in an application. Remember the days of being serenaded by Sinatra while we hard-coded the paths in the controller.rb file itself? Those days are behind us now, and while we can appreciate Sinatra's diddies every once in awhile, we also have more things to learn and do.

Now the Rails "magic" begins. As usual, we have a Request-Response cycle. First, the browser request made to an application is received by the router. Now we're in the routes.rb file, which lives in the config folder of an application (app/config/routes.rb) and contains all of our routes. The responsibility of a route is to match the HTTP request with the appropriate controller and its corresponding action in order to ultimately render a response to the browser for viewing, thus completing an iteration of the Request-Response cycle.

Next we should mention REST.

There are essentially seven RESTful actions we should use when working with an object connected to a database in our application.

HTTP Verb	Method	Description
GET	index	Show all pokeballs
POST	create	Create a new pokeball
GET	new	Render the form for creating a new pokeball
GET	edit	Render the form for editing a pokeball
GET	show	Show a single pokeball
PATCH	update	Update a single pokeball
DELETE	destroy	Delete a single pokeball

Table structure from Learn.Co

We can use Rails efficiently and effectively by incorporating RESTful Standards. REST stands for REpresentational State Transfer. By being RESTful, we'll be able to match up our routes with our controller (and model through controller), and views in a flash.

Here's the routes.rb file

However, we can refactor this into:

Rails essentially allows us to use the resources method to access all of the RESTful actions for the PokeballsController.

You can read here for more on resources in routes.

Now the controller (Not all filled out)

Last but not least, a look at the views/pokeballs directory containing the embedded Ruby files to be rendered by our PokeballsController actions.

See the similarities? It’s no coincidence that the actions are matching up both in the routes, controller, AND the files in views that our application will ultimately render for the user to see. The response has matched the request.

Everything is connected.

Naming conventions are incredibly important with RESTful standards and Rails, so it's helpful to keep in mind when setting up your application. Convention over configuration is key when using Rails. By utilizing proper naming conventions, we can match HTTP Verbs and URL paths with controller actions, and corresponding pages to render.

We're going to use an example to hopefully make things clearer.

So Dora the Explorer wants to become a Pokemon Trainer.

Day 1 - Fierce and Determined

Exploring is no longer enough and she seeks the thrill of battle. Boots is her Starter Pokemon and her next step is to acquire Pokeballs to capture more Pokemon. (Pokeball is the model)
Dora has to take many different "routes" to: accomplish certain "#actions" to the Pokeballs she collects.

Now Dora could hard-code her "routes" on her map, but then she's at the mercy of unforeseen dangers and Swiper.

Look how proud Dora is of her hard-coded route. Don't be like Dora.

That being said, it'd be much more efficient and effective for Dora to trust in one of her best friends, the Map. The Map serves as both the routes in routes.rb and the controller with its corresponding actions, for Pokeballs in this case. This Map not only talks but has the ability to be "dynamic". This means that the Map can adjust the path to get to Dora's desired destination.

All Dora has to do is follow RESTful standards when communicating with the Map and tell him where she wants to go. In order to have the corresponding action done to a Pokeball(s), the Map checks the route and matches the HTTP verb and URL path to a PokeballsController and action, ensuring Dora arrives at her destination. Dora has a lot on her mind and would rather entrust all of this navigation to Map.

By following RESTful standards (ie naming convention with the seven RESTful actions), Dora and Map work in sync.

Just tell the Map where you need to go

I hope RESTful Standards and routes make a bit more sense.

Do be like Snorlax and use REST on Rails.

Every once in awhile, remember to appreciate what Rails does for you.