REST? Wut?

This is embarrassing to admit, but a year or so ago, I didn’t really know what REST was. I remember that I was poking around the Twitter developer documentation, trying to figure out how to get a certain location’s Twitter trends. Based on keywords alone, GET trends/place looked like it was what I needed, and it was what I eventually used, but at the time I didn’t truly understand how to work with API endpoints. I was just bumbling along, trying to get my one little piece of data. I didn’t see the patterns.

Anyways, embarrassing. I can laugh about it now because REST is awesome!

So… what is REST? REST stands for REpresentational State Transfer. It’s an architectural style for how systems can communicate with one another. One key differentiator of REST is that it’s “resource based” instead of action based. What’s a resource? It’s generally anything that you want to provide access to in your web app/service. That’s a pretty broad idea, but it’s easiest to think in terms of nouns. Here are some examples of resources from my recent Rails project, which was a vacation tracker: there’s a “trip” resource, “user” resource, “destination” resource, and an “attraction” resource.

What is RESTful routing?

So far in my learning, REST has come up most often in routing my web apps. Apparently, back in the wild west days of the Internet, there were no conventions in place for handling URLs. A URL for creating a new blog post could be “www.bloggy.com/draft-new-post” on one site, and “www.wonderblog.com/new-blogpost” on another site.

RESTful routing uses a combination of HTTP VERB & URI. This design leads to a predictable mapping between the URL resource & the corresponding controller CRUD actions. This consistency makes things better for everyone, users and developers alike.

Continuing with my project example, this means that I can get and send information about each of these “resources” by using specific combinations of VERBS & URLS. This is nice because you can reuse the same URL for multiple needs. RESTful design makes for cleaner, shorter, and more predictable URLs. Rails is all about conventions, so it’s no surprise that Rails makes it easy to implement a RESTful design pattern.

There’s seven possible RESTful route options available, to correspond to seven controller actions.

As a refresher, the  CONTROLLER ACTIONS include:::

1. Index – shows an index page for the resource
2. Create – creates a new resource
3. New – renders the page/form for creating the new resource
4. Edit – edits an existing resource
5. Show – shows a specific/individual resource
6. Update – updates an existing resource
7. Destroy – deletes the resource

 

And the HTTP VERBS used include:::

1. GET – this method retrieves data
2. POST – sends data (via forms for example)
3. PATCH/PUT – updates existing data
4. DELETE – deletes the record

 

And here’s what the seven RESTful routes looks like in my Rails app for the Trip resource:

HTTP Verb / URL path / Controller action

1. GET            /trips                   # Index – Show all trips
2. POST          /trips                  # Create – Create a new trip
3. GET            /trips/new          # New – Renders the form for creating a new trip
4. GET            /trips/:id/edit      # Edit – Renders the form for editing an existing trip
5. GET            /trips/:id              # Show – Show a single trip
6. PATCH       /trips/:id              # Update – Update a trip
7. DELETE     /trips/:id              # Destroy – Delete a trip

When I was first learning about the routing conventions it was a bit overwhelming, but you basically just have to see examples of this over and over again to get it. When you finally do, you’ll love REST too.

Here are a few more helpful and in-depth resources:

• “How I Explained REST to My Wife” – The original was removed due to concerns over sexism, but it’s still live here.
• “What is REST?”