CRUD, HTTP, and RESTful Routing; the Backbones of the Modern Web
As a student web developer attending Flatiron School’s immersive software engineering course, I have spent the last two weeks learning the basics of Ruby on Rails. Ruby on Rails (we’ll call it Rails from now on; hello saved keystrokes) is a framework built in the Ruby programming language that is intended to make designing and deploying web applications fast, (relatively) simple, and fun. One of the pivotal ways in which Rails achieves this is by encouraging developers to adhere to RESTful principles when writing our routes.
Our introduction to Rails was framed to us as our entry in to building web-based applications. In the previous phase of the program, we had learned the basics of object oriented programming, domain modeling, and database management. In the end, we were tasked with building a command line application with full CRUD functionality. Making the leap from building a command line app to building web-apps sounded daunting at first, but Rails made the transition relatively natural thanks to the ways in which its routing conventions map seamlessly with CRUD actions.
Want to read this story later? Save it in Journal.
So what is CRUD? The acronym stands for ‘create, read, update, destroy’, and it refers to the basic ways in which users might interact with our app, and the data in our database. It is easy to imagine almost any web-based application that you have ever used and feel familiar with what these four actions represent. Let’s use Medium.com as an example:
- Create — Write a brand new Medium post and save it, creating a new entry in Medium’s database
- Read — Fetch a post from Medium’s database for viewing; view the post you just created, or view a post that another user has created
- Update — Go back to a post that you created and edit it, change the values associated with that post in Medium’s database
- Destroy — Maybe that post wasn’t such a great idea after all, time to delete it and permanently remove it from Medium’s database
This may all sound very simple, but CRUD is one of the core principles of creating interactive software on the web. As users, all of this is as easy as clicking a button or a link in order to make something happen. What happens when we click that save button in order to create a post? How does that simple action result in our browser sending data to a server somewhere else in the world, along with a request to save that data in the server’s database? Now that we know what CRUD is, there are two more very important concepts that will illuminate the answer to the above question: HTTP and RESTful routing.
HTTP (Hyper Text Transfer Protocol) is the protocol that fuels the web. It is the foundation of nearly every interaction between a client machine and a server somewhere else in the world. When we enter ‘www.medium.com’ into our browser’s address bar, we are making an HTTP request to Medium’s servers, the data that we get back as a result of said request is the server’s response. Once the server sends back that data, it forgets entirely about the request that it is responding to, and continues to sit and wait patiently for the next one. Each proceeding interaction we have with the website is going to have a corresponding HTTP request that gets sent to the server.
Each HTTP request we make comes with a verb, or method, in its header that indicates to the server the nature of the request. If you’re like me, you spend most of your time on the web making what is called a GET request, i.e.: get me some data that I can look at in my browser. But say you’re a very active blogger, or tweeter. In that case, you are also making many POST requests. This is when the client sends data back to the server and requests for the data to be saved in the server’s database. You’ve probably also fired off some regrettable tweets in your lifetime that you’ve felt the need to go back to and either edit or delete. In these cases, you are making a PUT or DELETE request, respectively.
As you can see, HTTP requests and their respective verbs map seamlessly with the basic CRUD actions that we established above. At this point, if you’re saying to yourself, “but wait, I’ve never told my browser to make a GET request in my life, what the heck is this guy talking about?”, you’d be asking yourself a very fair question. When you click on that website link to view the associated resource, how does your browser know to send a GET request to the server and not a DELETE? The short answer is that the developers designed their website to do it for you. More often than not, they used a convention called RESTful routing in their back end in order to achieve this.
Disclaimer: REST (Representational State Transfer) is a massive topic that goes much deeper than the routing aspect. In short it is a style of web architecture, or set of design restraints, that was introduced to the world by a computer scientist named Roy Fielding in his 2000 dissertation: ‘Architectural Styles and the Design of Network-based Software Architectures’. There is often debate amongst developers around whether or not a particular web service is or is not “RESTful” (for example this Stack Overflow post about whether Twitter follows RESTful conventions). How do we make this determination? Again, this is a deep subject that I have only barely scratched the surface of, but a good place to start is by simply looking at how the routes that end up in our browser’s address bar are written.
So what do we mean when we talk about routes and routing? Right now, as I work on this blog post, I am in a particular destination in Medium.com’s infrastructure. Specifically, if I look at my address bar I am at ‘medium.com/p/some-big-long-number/edit’. Thanks to my new-found knowledge of RESTful routing, I can actually make a pretty educated guess as to what this all means. The ‘medium.com’ portion of the URL is, of course, the entire domain of Medium.com, the really interesting stuff is what occurs after each ‘/’ character. The ‘/p’, I’m going to go ahead and assume, is short for ‘post’. The ‘/big-long-number’ portion is my post’s id, the number associated with my post in Medium’s database. Finally, the ‘/edit’, is saying to the server, “Take me to the place in your domain’s infrastructure where I can actually edit this specific post, and not just look at it.”
The id portion of the URL is really the most interesting part, it is dynamic and can change depending on which specific post a user is trying to edit. Theoretically, if I could somehow figure out the id number of another user’s post, and were a malicious person (I like to think I am not), I could plug that id number into the exact same URL and begin editing some post that does not belong to me. Side note, this probably would not work because Medium most likely has implemented some kind of authorization feature on their server that prevents such a thing, but that is a whole other can of worms. Ah, the internet; turtle’s all the way down!
The only reason I am able to make all of these assumptions is because I have seen these patterns implemented in the exact same way in my own experiments with building servers to host web applications. That is really the whole key to RESTful routing, it is standardized and pattern-based. It creates a convention for web architects to follow which then frees them up to work on the actual unique things about their application.
This convention is so common, in fact, that there are a plethora of resources all over the web that will show us exactly how to write a RESTful route for any given resource in our application. Check out the following table from RESTular.com:
All I did was type in the name of a theoretical resource, and I was given all of the ways to write each of the routes that I might create for users to interact with said resource. It is easy to break these conventions, but you may find that you’re creating a big mess for yourself if you do.
In summary, HTTP, CRUD, and RESTful routing are all closely related concepts that build on top of each other in order to create a standardized, pattern-based model of web service architecture. We ought to be grateful to all of the incredibly clever people who came before us who devised these schemes. We don’t need to reinvent the wheel or do anything super clever in order to ‘wire up’ the data on our back end for users to interact with. We merely need to follow the conventions that have already been laid out for us. Because of this, we get to spend time doing the fun stuff: modeling our domain, creating interesting ways in which to interact with our resources, and writing logic that make our apps more dynamic and interesting.
Thank for reading! For additional (probably more helpful) resources on the above concepts, see the following:
- REST wikipedia page
- HTTP wikipedia page
- YouTube video of charming, zany person breaking down RESTful routing (very helpful!)
- For a doozy of a read: Roy Fielding’s dissertation
📝 Save this story in Journal.
