Is It Safe to REST on Rails?

If you were to ask me this question a year ago, you would be met with a horrified expression, an immediate, “no”, and a concerned, “Is everything alright? However, after joining the world of coding, I understand this very terrible play on words and can confidently say that “Yes it is!” Similar to the boy in the picture above, we as Rubyist’s, should be more than comfortable with the abilty to “REST” while on Rails. More specifically, using Rails’ built in RESTful principles to help navigate your web app.

For the people not in the know, what does it mean to REST? The acronym stands for REpresentational State Transfer. It’s a little hard to explain in english and I won’t bore you with the details but to sum it up, back in the day URL’s were long and stressful to look at and now, thanks to REST, they’re a little easier to read and navigate through because we’re using the representation of a resource to transfer information between a server and a client. If you want a little more information checkout this page but I’m sure my definition is helpful enough, right?

Great! So, let’s say we wanted to use REST and perform some CRUD actions on a web app about Unicorns. Quick recap on CRUD, C is for Create, R is for Read, U for Update, and D for Destroy. Now that we have that down let's ask ourselves, what do we want to do? Well, we’d want to display every unicorn our database. Maybe give the user the ability to CREATE a unicorn that wasn’t already in our database? How about a page where a user could READ information about any unicorn of their choosing? Even give the access to UPDATE or DELETE the information for any unicorn? (See what I did there?)

Unicorn Time??

Hold your horses! Before we can get started, there’s one more thing we should take a look at and it’s HTTP Verbs. For each of these CRUD actions, HTTP Verbs are necessary for unicorn enthusiasts to request from our server. Some HTTP Verbs we’ll need for this are GET, POST, PATCH and DELETE. A GET request returns a page that displays information. A POST request calls on an action to create new information for the database. A PATCH request will update information that is already on the database. A DELETE request, to no one’s surprise, deletes information from a database.

PUT is also a verb but we will not but using it in our scenario

Lets start by displaying all of our Unicorns on a page. First, we match up a HTTP verb with the route, in this case, the verb would be “GET” and the route “/unicorns”. Next, we want to point that route to an action in the appropirate controller. For a page showing an “index” of all our unicorns, we could point it to the (you guessed it), index action! The index action for the unicorns controller would look something like “unicorns#index.” Mix it all together and we have…

get "/unicorns", to: "unicorns#index"

Quick Tip: If you’re not a fan of writing out the route “/unicorns” over and over again, you could add an option, :as, followed by a name you think is easier to remember for yourself, in this case lets call it “unicorns”. Doing so allows you to call unicorns_path, in place of “/unicorns”, anytime you would like to make a GET request to the page of all unicorns.

So now we do the same process for the other actions we want to call on and we will end up..

#REMEMBER THE :as IS OPTIONAL
get "/unicorns", to: "unicorns#index", as: "unicorns"
get "/unicorns/new", to: "unicorns#new", as: "new_unicorn"
post "/unicorns", to: "unicorns#create"
get "/unicorns/:id", to: "unicorns#show", as: "unicorn"
get "/unicorns/:id/edit", to: "unicorns#edit", as: "edit_unicorn"
patch "/unicorns/:id", to: "unicorns#update"
delete "/unicorns/:id", to: "unicorns#destroy"

Kind of confusing to remember and write out isn’t? In comes the most useful source I’ve found for help when it comes to routing my apps, Restular.com.

Restular.com

If you’re someone who struggles with routing, view files, or HTTP verbs, this site is the cheatsheet of all cheatsheets. By simply typing the name of the table you would like a route for, it gives you the 7 routes used for CRUD actions. Not only will it show you the HTTP request type and URL path of the route, but it will also give you a short but informative description of what that path is doing.

Still a little confused? Can you keep a secret?

Shhh

resources :unicorns

Instead of having to write all 7 lines of code like before, that one line is used to accomplish the same thing, but where’s the fun in that? Since were on the topic, here’s another quick tip, using Rails’ resource generator, like so

rails generate resource Unicorn

in addition to creating a model, controller, migration and some tests, it also adds resources to your routes for you. For a beginner coder like myself though this is still black magic and I don’t recommend using it unless you have a proper understanding of the 7 lines we saw earlier. So for now, this stays between us…

Now you may be asking yourself, “Where’s my unicorns at?” The next few steps, building out your controller and view pages, I want to cover later in a future blog. No need to overload your brain with too much new information at once right? For now, lets get the routes down til we’re all comfortable, no use building Rails without a Route, right?…

Happy Coding!