Resources and RESTful routes in Ruby on Rails
Resources is just a method provided by the rails gem. That’s right, ‘is’. And because resources is a method, resources will perform some kind of action. In rails the resources method allows us to transform a resource through CRUD actions. A resource is a simply an object represented by a model and acted on through a controller. But, because in both rails and the english language a ‘resource’ is referring to a thing of some kind, one might think that resources ought to be the plural version of a noun rather than what it is in rails, a verb. Another mystifying thing about the resources method being plural is that it might seem like it’s more than one method, but it’s not.
In the english language there are several ways the word ‘resource’ is defined (both as a noun and as a verb). To think about the meaning of the word ‘resources’ in relation to the way rails uses resources I found this particular definition to be relevant. According to Oxford dictionary:
/ˈrēˌsôrs,rəˈsôrs/
verb
3rd person present: resources
provide (a person or organization) with materials, money, staff, and other assets necessary for effective operation.
example:
“ensuring that primary healthcare workers are adequately resourced”
Origin:
early 17th century: from Old French resourse, resource (“a source, spring”), from Old French resourdre, based on Latin resurgere (“to rise again, spring up anew”) based on Latin surgere (“to rise”)
Understanding the way Rails uses the word resources can be a little confusing at first. But it begins to make sense once you break it down and think about it in context. As for the word ‘resource’, even though we may think of it mainly as a noun, it can also be used as a verb. Either way, whether it’s a noun or a verb, whether we are speaking English or Rails, a resource implies a verb because resources are things people use. Resources are always used in some way. Then going back to Ruby on Rails and thinking about the word ‘route’, a route declares a path to travel (which is true in English as well). Therefore a route is a noun with the implication of a verb. A resource in rails the same thing. It is a noun with the implication of an action. It is resource whose route is ‘mapped’ to related requests. Resources lets us declare what actions we will implement on these requests. Using the MVC modeling convention, resources are declared inside our routes folder which then maps them to the various models in our application.
The resources method provides us with routes for the requests our application server receives. RESTful routes are REpresentational State Transfer routes. In addition to resources being built in, Rails has RESTful principles built in too. RESTful routes depend on the HTTP verb and the URL to indicate what part of the site to visit. With resources we can define what HTTP verbs we want a user to be able to use on a particular resource.
Resources map HTTP requests and URLs along RESTful routes to controller actions (read: CRUD actions (along with index, show and edit actions). Because CRUD actions are verbs it makes sense that the resources method should be thought of in relation to the action potential it provides (verb/CRUD potential) more than what an individual resource (nouns/models) is on its own. A resource is cool but resources is awesome. After all, what good is an app if a user can’t do anything?
An important aspect of Rails is its foundation in object oriented programming. From understanding Ruby we know that objects are essentially just messages in the form of code (nouns or verbs). And within Ruby nouns and verbs are treated equally, they are all just objects. On some levels their distinctions are important, but high level they’re all just objects. This is why calling naming this Rails routing method resources is kind of no big deal. In Rails we take objects in the form of HTTP requests and URLs and route them to their corresponding models and actions. This can be done through resources. We can then organize objects in tables in the database according to their model calls. Inside the models objects are then connected to each other according to their associations. Through the rails way of directing the traffic of our data we ensure that our app conforms to MVC protocol. This also DRYs out our code. Then the objects are returned from the database, to the models, to the controller, then sent to views as instance variables which are formatted (in HTML), sent back to the controller and then sent to the client via the browser. All things considered starting with routes/resources we can give our applications the organizational starting point needed to create dynamic, associative pages with a variety of user inputs. This provides a more interactive, powerful application.
