CRUD, HTTP Verbs and REST… Oh My
When I first learned about Ruby on Rails and the finer points of web development, I remember being utterly confused between CRUD, HTTP Verbs and then REST. They were used in sentences interchangeably (or so I thought) and when I looked each up, it all sounded like they were all doing the same thing. I thought one of the major tenets of being a programmer was to mitigate repetition!
There are differences in how the three distinguish themselves and knowing the roles they each play in the request/response cycle helped me understand the greater picture of web development. Here’s what I learned!
Let’s start with CRUD. You can think of these as action verbs, what actions do you want to take regarding your data? Every time you enter your information on a form to sign up to something, you’re CREATING a user account. When you enter a search term in Google, what do you expect to happen upon hitting enter? You want to READ a series of possible answers to your search query. Let’s say you change addresses, all your bank accounts have to be UPDATED. After Game of Thrones, you DELETE your HBO account. These are the basic actions that occur in all web applications connected to a database. Whenever referring to CRUD, you’re in the mindset of “What, overall, am I trying to do?”.
I hit upon this a little bit in the above examples, but these are specific to the frontend side of web applications, anything a user sees. This all falls in with the request/response cycle. When you type in the address bar ‘google.com’, what do you want to happen? You want to be directed to google.com! You aren’t making any changes or pushing new information, you just want to view the page… you want to “READ” the page (think CRUD). OK, but in the context of the client-side, when you type ‘google.com’ into the address bar and hit enter, you are making an HTTP GET request. The webpage is taking your input and on your behalf, politely asking the server to GET some information so you can READ it. The server will respond by sending the requested information, or tell you that there was an error in the request.
Similarly, if you want to create a new account on Twitter, you fill out the form and hit enter, you are making a POST request, asking the server to CREATE a new account. You realize that ‘cupcakeFiend’ is not the twitter handle you want, so you bring up your account information and change your handle to ‘cookieMonsta’, hit enter and you are making a PATCH request, asking the server to UPDATE your account information.
- ** Side note, PUT and PATCH requests are somewhat similar in that they are related to UPDATing records, but where PATCH will only update your handle, PUT will update your entire account information.
- https://www.testingexcellence.com/difference-put-patch-requests/
The next day, you wake up in a cold sweat and realize you don’t want to expose your secret life of baking to the world and click on the option to deactivate your account. You are making a DELETE request for the server to… you guessed it… DELETE your account.
OK, we’ve covered the actions verbs of CRUD and the client-side requests a web page makes in the form of HTTP verbs. Welcome to the server-side RESTful Routes. REST stands for REpresentation State Transfer, it’s an architectural design pattern that was created to mitigate the complete chaos in naming routes that existed in the early days of web application building.
Think about all the web sites you visit, ESPN.com, Wayfair.com, Etsy.com, etc. Those sites all do fairly similar things: there’s a home page that displays all the categories you can explore; when you click on a specific category the page directs you to another page where you can further narrow the category. You can click on a very specific item and it’ll show you all the information pertaining to that one item. There are forms that allow you to create a record or update a record (whether it’s an account or another piece of data), and there are avenues for deleting/destroying some of those records as well. Have you ever taken notice of the address bar when you’re performing these actions? Notice how they change depending on what function you’re trying to achieve?
Reference the table below. Next to each HTTP verb, you’ll see what looks like part of a URL address, followed by some words and #, and finally what each row is used for. There are 7 RESTful routes: INDEX, NEW, CREATE, SHOW, EDIT, UPDATE and DESTROY. Recall the request and response cycle, the HTTP verbs are making a request to the server, the server sends back a response but how does it know what is being requested?
I go to photography.com/photos, and I get the homepage with a display of all photographs. But I don’t care about all photos, I’m only interested in the one photo of my favorite golden barrel cactus, but how the heck is photography.com going to know that? I have to direct the server by typing photography.com/photos/1
Let’s start at the very beginning, I typed photography.com/photos in the address bar and hit enter. The browser sent a GET request to the server of photography.com, asking them to respond with the information regarding all photos. As a user, I want to READ that response.
Photography.com see the route /photos and recognizes that it is being directed to the INDEX controller action (when building out the website, unless I specify that a click is supposed to CREATE, it will default to INDEX). The INDEX controller action is only responsible for showing all the photos. If I typed in /photos/1 then the web page will be directed to the SHOW controller action which is only responsible for displaying the one specific photo.
Bringing it all Together
It may be confusing juggling the three contexts of CRUD, HTTP verbs and RESTful Routes. But that’s really all there is, context. There are the client and the server, with some degree of mediation between the two, but depending on which side you’re on will determine whether you’re using the HTTP verb or the RESTful routes. On either, a CRUD action is either being requested or being fulfilled.
