Conventions: REST
In this series, I will briefly discuss different programming conventions and why we follow them.
The first entry in this series will cover ReST, or Representational State Transfer. REST is an architecture for which we handle sending, receiving, and manipulating data on the web.
There are 3 main components that go into handling data manipulation on the web: a route, a resource, and a verb.
Verbs
We can first begin with the verb. More specifically, an HTTP Verb is used to decide how we want to manipulate data. There are five total verbs: Get, Post, Put, Patch, and Delete.
Get and Delete are fairly straightforward, they simply describe reading and removing data, respectively. When you clicked the link to view this article, you made a Get request to Medium’s server, essentially asking to see it. If I were to click the little trash can icon next to this article, I would then be making a Delete request to Medium’s server, saying that I want it removed.
Post is the verb that allows us to send data. Whenever you send a Post request, it is very likely there is also some kind of data being sent with it. A good example of a Post request is a Post. When I click the Publish button for this article, I will have sent a Post request to Medium’s server with the data contained in my article.
Put and Patch are verbs that are used to edit data. They’re almost basically synonymous, but there is an important difference. Patch is used to overwrite data directly, Put essentially makes a new copy and replaces the old one.
Resources and Routes
I decided to group the other two components together, as its difficult to have one without the other. When we send a request using a verb, where are we sending it to? That’s where the route and resource come in.
The resource is self-explanatory, it’s the type of data we want to see. The route is quite literally the route we need to take to actually interact with the data.
Let’s use this post as an example. If you look in the search bar of your browser, it should read:
https://medium.com/p/75630f300144Everything after the .com is considered the route. As I’m writing this, my search bar reads almost the same:
https://medium.com/p/75630f300144/editThe difference here is that since I’m currently editing this post, I’m at the edit route. When I click the button to publish, I’ll have sent either a Put or Patch request with the finalized draft. In fact, while I’m typing this, every time I stop typing for longer than a few seconds, I see a notification that the post saved. That means it’s constantly using Put/Patch to make sure I don’t lose my progress. Thanks Medium!
All Together Now
Just in case the upper examples were confusing, I want to do one more final breakdown in a more simplified manner. In the example, I’ll be using articles as the resource. Here is a list of RESTful routes, what verbs they use, and the kind of action they will make, respectively:
GET '/articles' is an INDEX action, we are asking to see a list of articlesGET '/articles/new' is a NEW action, we are asking to see a form to start compiling data to create a new piece of data to submitPOST '/articles' is a CREATE action, we are submitting the compiled data to the server to try to save itGET '/articles/1' is a SHOW action, where the 1 represents a unique ID to find a specific article, in this case, the first article ever submitted because it would have an ID of 1GET '/articles/1/edit' is an EDIT action, where we would be able to see data fields with the articles information available for us to changePATCH/PUT '/articles/1' is an UPDATE action, similar to the NEW and CREATE actions above, we are now submitting the updated data to be savedDELETE '/articles/1' is a DELETE action, where we would attempt to remove or destroy the first article in the database
Hopefully by now I’ve done a well enough to job to give you a basic understanding of how we make web requests and how REST is designed to handle those requests in an organized manner.