I’ve been reading over The Rails 3 Way by: Obie Fernandez recently. I’ve been focused on chapter 3 where he discusses Routing quite thoroughly. Today, I’ll cover one of the sections from my reading. If you’re just starting out in Rails and find yourself using Rails 4x. Consider checking out his book specifically for Rails 4, which is set to come out in the spring of 2014 on Amazon.
The first thing I learned right off the bat in chapter 3 is what a resource actually is. Its just a high level representation of what we’re looking for when submitting a browser request.
Here are two excerpts from the book:
What you actually do get hold of is never the resource itself, but a representation of it.
A resource may, at any given point, be available in any number of representations (including zero). Thus your site might offer a text version of The Little Prince, but also an audio version. Those two versions would be understood as the same resource, and would be retrieved via the same identifier (URI). The difference in content type-one representation vs. another-would be negotiated separately in the request.
My take from this is that a resource is a way of first structuring data and then communicating this data to either the browser or into the database through HTTP verbs.
There are four HTTP verbs that Rails uses to communicate via a request. They are GET POST PUT and DELETE. Rails creates four named_routes mapping to 7 controller actions by having two of the named routes
objects_path or objects_url and
object_url(@object) map to more than one HTTP verb depending on the desired action needed.
In Rails most if not all of the heavy lifting has been taken care of for us if we decide to establish our routes using the
Here’s an example:
New & GET meets Create & POST
The Create action is the RESTfull action that will POST client data (i.e. data from a user’s submission) that was entered into the New action template’s form_fields. This New action will use the HTTP GET verb to structure a representation from the request data organized by the form we would have created. When the user clicks the submit button on their form, the data gets set into a prams hash, which is considered a saved representation of this resource once committed to our database.
Here’s an example of this from the viewpoint of our server logs:
Here is a snapshot of whats going on behind the scenes when I click on the sign_up button which initiated a GET request to the controller. The controller will understand the specific data I will need for this action (because I’ve defined it in the specific controller method/action), and then returns the correct view template (devise/registrations/new.html.erb) renders both the data and the pre-defined view templates in one representational package to the browser.
And this is the POST action in… Action! It starts by establishing the correct routing for the request (which was initiated by the user clicking the submit button) to the
I’m not entirely sure if POST is creating a params hash or using a pre-existing and empty params hash, although I am leaning towards the prior. In either case, POST is committing the resource composites to our database, which starts where the
(0.5ms) BEGIN sql statement starts in the illustration above.
So to wrap up, the REST conventions that Rails provides can characterize communication between a client and the application server, and the responses of which are representations of resources. A resource in this context, is a “conceptual mapping”. A resource isn’t tied to a database, a model, or a controller, and is basically a high-level description of the thing we’re trying to get when we submit a request.
Some examples of a resource that I’ve gathered from the book include:
- The current time of day
- A library book’s borrowing history
- The entire text of The Little Prince
- A map of jacksonville Beach
- The inventory of a store
To me it appears as though a resource is a group of data not bound by a specific file or related set of files in our application, that expresses a collaborative representation of what our end user wanted to see based on both the features we have provided as programmers, and the requests that the user is making to our applications controller. The controller has a hand that reaches for the associated data that the client has specified, and another hand which will populate this data in a template so that it looks presentable.
I have a ways to go before I can say that I grasp all or even most of the concepts involved with Rails routing, and if you have anything to add/critique, feel free to comment!