AND NOW WE "REST"
- Winnie Au
- Sep 2, 2015
- 3 min read
This morning during standup, our coach asked if anyone had ideas about how Rails encourages the building of RESTful applications, and I jokingly said "Umm, because it allows us to sit back while it does its opinionated things?" Despite the fact that I said this totally in jest without actually knowing anything, I now see that I was at least partially right. I can't say I understand completely, but it seems that Rails has this way of simplifying application building and I have a feeling it has to do with the fact that it adopts conventions rather than configuration.
Think about the furniture in your home. Rails is like a brand new chaise lounge that's been hand-delivered by some studly moving men. It comes out of the box, ready to use in mint RESTful condition. Meanwhile, trying to build an unRESTful application is like trying to silently direct a couple with poor communication skills during a particularly sad attempt at building the Liatorp aka "divorce maker" from IKEA (see the below link for more on this lovely gargantuan thing and its supposed effect on couples).
According to Mike Clark, author of "Advanced Rails Recipes: 84 Ways to Build Stunning Rails Apps", "[Rails] takes the grunt work and it moves it aside. It says we're going to adopt some conventions, and as long as you're cool with the conventions then things are going to go much smoother for you. So you can really concentrate on what you intend to do, which is build an application. You can really concentrate on your domain and the things you want to add to your domain and not have to concentrate on all the plumbing and configuration things."
Let's get more specific. In an earlier post, I explored the meaning of REST. As a reminder, Representational State Transfer is an architectural style for building "scalable web services". It can be described by several constraints which include Uniform Interface, Stateless existence, Cacheable, Client-Server and Layered System. So how is Ruby on Rails RESTful?
Turns out I was right about the emphasis of convention over configuration. Guess what! No more lengthy XML configuration files! Apparently, there aren't any in Rails?!? Rails automatically maps database tables to Ruby objects. Your application code and running database already contain everything Rails needs to know. Also, because of all the work Rails does for you, this means fewer lines of code, fewer bugs (statistically speaking), code that is (hopefully) more readable and more easily maintained.
A RESTful application tends to have a limited number of operations/methods between clients and services. Resources (the objects receiving the actions) are given their own unique URIs (Universal Resource Identifiers). Because each operation has a specific meaning (GET, POST, PUT and DELETE), REST avoids ambiguity.
Rails can automatically create a full set of CRUD (Create, Retrieve, Update, and Delete) operations and views on any database table. You can just jump right into manipulating those database tables. Is that RESTful or what? Like an amuse-bouche on a summer's eve.
So how does a request get passed along to application code in Rails?
An incoming request is sent to a router. The request is then parsed by the router to identify a particular method somewhere in the controller code.The router takes the first part as a controller name and the second part as a method name.The action might look at data in the request itself, interact with the model or invoke another action. Eventually, the action prepares information for the view. The view renders something to the user.
Here is a diagram to help any visual learners out there:
So what have we learned? If you're going to build an app, just make it RESTful. Rails can help you! And maybe think twice about the Liatorp if your relationship is already on the rocks.
Resources
Comentarios