Representational state transfer (REST) is a convention that is simple and much needed in a community the is built on cooperation. Imagine trying to get gas for your car and the nozzle from the pump was the wrong size or the wrong shape. Getting gas would become a task that causes much grief and headache. Thankfully, the gas people have all agreed that they should work together to make things easier for manufacturers and consumers alike. This is essentially what RESTful architecture does for web services. Standardizing architecture allows consumers to access resources easily and consistently without having to reinvent the wheel. It makes design easy for engineers since they have a framework that is proven and scales to the size of a project. Basically, REST is awesome and it’s actually very easy to understand.
There are seven primary paths we use in Ruby on Rails. Get requests are pretty self-explanatory, they get data from a server. The naming conventions make it easy for users and developers to understand as well. If a user wants to see a list of all of a specific resource, the link is named the plural form of whatever resource it represents. Restaurant.com/meals would be an example of a link to a list of meals at restaurant.com. This is pretty easy to understand but it could quickly become difficult if we didn’t follow the RESTful architectural style. Imagine someone wanted to call the list of meals ‘resources’ or something ambiguous like ‘sustenance’. While both may be accurate, they are less than helpful.
If a user wanted to create a new meal (assuming you could do that at restaurant.com), the user could go to restaurant.com/meals/new. The URL sent back to the server contains the data the user input and this is called a POST request. Basically, restaurants.com, this is the data we want you to use to make a meal: restaurant.com/meals/name=user_made_a_new_meal. The server can route the data to the controller and process the new meal and the convention is to route the user to the ‘show’ view of meals at restaurant.com/meals/:id — the ‘:id’ is a wild card that represents a unique identifier (a number in beginner Ruby cases).
Users can edit their meals at restaurant.com/meals/:id/edit. This is also a ‘get’ request since the user gets the data they want to edit. The response the user sends back is a patch (can also be a post or put) and the edited data is handled in much the same was a new meal. Finally, users can send a delete request to restaurant.com/meal/:id to delete a meal.
These all may seem simple and obvious and that is exactly the point. RESTful APIs show us how easy things can work when everyone involved works together. When I was first introduced to RESTful APIs, the explanations I received were all but helpful. I like stupid simple color-coded explanations. It’s not hard. Part of the architectural style is to make it easy to read and handle data from any resource. Links for a website should all but shout what they lead to if they are to follow restful conventions. There is much more to it than simply naming things pretty, but that’s the gist and an explanation I should have found easily considering the vast amount of resources at my fingertips.
Developers who follow RESTful convention can work together seamlessly since they have constraints that specify what specific verbs, actions, and routes should do. I know when I look up a RESTful API and I want data, it will be through a get request that goes through a show action or an index action most likely. I don’t really have to look up much since REST takes care of how this all should work. In fact, you can often get data from a resource without having to dig too deep into the data structure because once you have the basics, you can experiment and find out where all the good data is kept.
The importance of working together for software engineers is immeasurable. Much like gas stations in the US, we pretty much all use the internet. Imagine if you couldn’t reach a website because you didn’t know how to get to it? Maybe the designers behind your favorite Marvel fansite couldn’t easily access the vast amount of data that is the Marvel universe? Managing hundreds of superheroes and villains would be tedious and labor-intensive without the proper tools. If I have learned anything thus far it’s that developers do not like to do work that is repetitive if it can be automated. Myself included. It’s fun to build a tool that makes work easier as well.
Back to REST. It’s a simple concept at its core that makes not simple work much easier and cohesive. I love to understand things and be able to explain something simply so that’s as simple as I can make it in about five minutes' worth of reading. May the force be with you.
