CRUD, REST and “the Cloud” for non-developers
A friend of mine recently shared an article that encouraged web and mobile designers to learn a few key technical skills in order to better understand the medium they design for. One of the main concepts the author recommended understanding was REST, or representational state transfer. This is the backbone of the vast majority of web and mobile apps, so, I think it warrants a full explanation.
I spend most of my time writing backend APIs in Ruby on Rails for mobile and web apps, but, when a layperson asks me what I do for a living, I tend to tell them this:
You know when an app saves stuff to “the cloud”? Well, I write the “Cloud”!
Most people have some vague notion of what the Cloud is, but, in reality, it can be thought of as a whole bunch of computers that you talk to via the internet in order to save and retrieve data. The major benefits of having these remote computers are persisting data so that you can access it from any of your devices, and sharing data amongst many different people. In order for data to persist and be shared to many users, we need to send data from any device and sync that data to many other devices.
When thinking about how we manipulate this data, we often talk about CRUD.
Developers will often use the word CRUD to talk about the most common set of ways of dealing with data and objects in our apps. It stands for “Create, Read, Update and Destroy” and covers the basic things you might need to do with data in almost all apps. The 4 actions in CRUD are as follows:
- Create — make a new resource
- Read — get the current state of a resource
- Update — change something about a resource
- Destroy — remove a resource
We use some combination of these four actions for almost all activities in almost all apps, from tweeting (creating a tweet), online shopping (reading a specific product), to TODO lists (destroying a TODO item).
When we break down the features of an app we are designing, it can be helpful to keep CRUD in mind, perhaps thinking of it as the building blocks from which we build more complicated functionality.
CRUD to the Cloud
If CRUD is the general idea of the things we can do with our data, then, how might we do that across the internet? When we do anything online, our client (which might be a web browser, a mobile app, a smart TV) performs a web request to a server (“the Cloud”) and receives a response from the server. Requests most often represent one of the CRUD actions, and the response most often represents a resource, whether that resource be a full web page, or, raw data representing the new state of a resource.
HTTP requests that are sent by our client go to an address (http://www.example.com/artists) and have a verb (GET). Sometimes we also send additional data representing a resource along with the request.
The 4 most common verbs are GET, POST, PUT and DELETE, and when paired with an address, these allow us to perform the CRUD actions (and more).
GET requests are used for reading. When we visit a web page, our browser sends a GET request to the server asking to read the contents of that page. When our mobile app needs to list things that have happened whilst we were away, we make a GET request for the list of things we are looking at.
POST requests are user for creating. Any time we submit a form on a website, our browser sends a POST request to create a new resource, maybe creating a new blog post, or, creating a new purchase on an online store. We send data along with the POST request, representing the new resource we want to create.
PUT (or it’s cousin PATCH) are used to update the status of a resource that already exists. If we change our Instagram bio or make corrections to a blog post, we are sending a PATCH request to update that pre-existing resource.
DELETE requests destroy resources. When something is no longer needed, we DELETE that resource to destroy it.
Whilst there are some other, more exotic, verbs; the 4 listed above allow us to accomplish virtually everything we need to do for our apps.
In broad terms, REST is a way of combining the HTTP verbs with some conventions around the URLs (web addresses) to perform the CRUD actions (and more besides).
Using the idea of an online music library, we can take a look at some simple examples.
We want to read the data about a particular song. We combine the GET verb with the address of that particular song (using the unique ID of the song we care about). In this case, we would:
This essentially says “READ the song ‘123’”, and the response from the server would be all the details about the song in question.
If we want to read the list of all songs, we again use the GET verb, but instead of having an ID on the end of the address, we request the entire collection:
This request means “List all the songs”, and the response here would be a list of all the songs available. This concept of reading a collection or list is commonly known as the “index”, (GET a collection), and the reading of a singular resource is known as “showing” a resource (GET a particular element within a collection).
Once we start wanting to add songs to the list, REST starts to become very helpful to us. In this case “Adding a song to the list” equates to creating a new song. To do this we combine the same collection (/songs) with a different verb — the POST verb:
Whereas GET requests often don’t need to send any additional data, POST requests allow us to attach a request body where we add a representation of the resource we want to create. How we represent that resource using a request body is a topic for another time, but, for now, just know that our request uses POST to add a new resource to the /songs collection.
The last two CRUD actions are further variations on this theme. To update a resource, we “PATCH it”:
and to destroy a resource, we (unsurprisingly) “DELETE it”:
Verb + Address = CRUD action
Whilst there is more to the full definition of REST and being RESTful, the core of the actions we perform on the web, on a mobile app or using any other method to interact with “the Cloud” can be condensed down to the CRUD actions.
Next time you use a web app, or perhaps as you design one, think about what data you’re creating, reading, updating or destroying, and how that most likely translates to one of the REST actions. Keeping this in mind can help us all understand better the underlying mechanism of how apps think about, and deal with, our data.