

In this section we’ll go into what’s actually happening with this file. Luckily, typing $ rails routes into the command line will give you an output of all the routes that are available to your application. Lots of training courses and tutorials kind of gloss over routes, and they seem quite easy in hindsight, but I remember learning Rails and getting hung up on what exactly is going on. If you open the routes file in your Rails app (located in config/routes.rb), you’ll see a huge blob of comments that do a pretty good job of explaining how it works, so you’re never in much danger of losing your way. That’s good for things like form submissions so that you later can use that form data to create or modify objects. The other handy thing that goes on when a request enters your application is that Rails grabs all the parameters that came with it and makes them available for you in a special hash called params that you can later use in your controller. If it can’t find a route that matches the request, your application will throw an error. It’s a pretty simple function but an essential one. It looks at the HTTP verb (GET, POST, PUT, DELETE) and the URL that is being requested and matches it with the appropriate controller action to run. The Router is basically just a matching service. Should we display the “new user” webpage? Should we edit an existing user with whatever data got sent along? When an HTTP request arrives from the user’s browser, it needs to know which controller action (method) should be run. The router is the doorman of your application.
