DEV Community

B Jacquet for Runtime Revolution

Posted on • Originally published at revs.runtime-revolution.com on

Calculating Route…

Photo by Nikita Kachanovsky on Unsplash

Ruby on Rails’ routing mechanism was the topic which took me the longest to grasp. Being the gateway between the application and the world, understanding its functionalities, possibilities, and restrictions is crucial to look ahead on how the User Experience can, will, may, or may not be.

Any RoR tutorial will tell you how simple it is to setup. “Just type in”

resources :product

“and you’ll have all of these routes automatically:”

Verb URI Pattern Controller#Action
GET /products products#index
GET /products/:id products#show
GET /products/new products#new
POST /products products#create
GET /products/:id/edit products#edit
PUT /products/:id products#update
PATCH /products/:id products#update
DELETE /products/:id products#destroy

Not having previous experience with RESTful APIs, I was a bit sceptical on how just five methods (GET, POST, PUT, PATCH, DELETE) are enough to provide all functionalities required for my application (or any application for that matter). What if I needed three different ways to update product? What if I needed routing for something which doesn’t have a model?

Turns out that mastering the routes.rb file is not that easy. ActionController::RoutingError was ranked the most common error amongst more than 1000 RoR projects, by Rollbar.

Ruby on Rails Guides’ page on Routing, although short on words, but with plenty of examples, is still quite a long page. Yet I suspect there’s more to say about it.

Vaidehi Joshi has a presentation on this subject with 123 slides! Spoiler alert: the talk is more about on how the routing mechanism is made.

Developing an MVP is fast and hard work. You follow your guts and act on a need to know basis — reflection comes after. Now, I have some time to look back at the routes.rb file. How little I knew at the time and what little more I know now. It’s obvious to me now that I can create a route for “not-modeled-something”. It’s also obvious that one can get away without a controller as well! Try it yourself:

Rails.application.routes.draw do
 get 'not-modeled-something', to: proc { [200, {}, [“Hello, controllerless!”]] }
end

For further reading, I’ve recently discovered this tutorial by RichOnRails.com which I believe to very complete. Happy reading and bon voyage!

Nowadays I work at Runtime Revolution. Working here has been a great learning experience, and I’m beginning to know a thing or two about Rails.


Top comments (0)