Who needs REST in the programming world?
REST is for the weak. Just have to code, code, code long into the night, right?
No, REST (Representation State Transfer) is a programming standard used in many languages for organizing ‘routes’ and making them reusable.
A ‘RESTful’ system is “stateless and separate(s) the concerns of client and server” — codecademy
It ensures that certain HTTP methods (GET, POST, PATCH, DELETE) are linked to certain CRUD actions (Create, Read, Update, Destroy). This makes the application and code easier to understand and creates consistent URL paths for users.
Client and Server
“A client is a computer that connects to and uses the resources of a remote computer or server” — Computer Hope
This can be all internal on a private server like in a corporate setting or local network.
Or, in the more common case of simply “browsing” the web, people use their client (aka personal computer) to input a URL address that goes out into the world-wide network of servers to find the files and information requested to return to the client.
Client can also refer to the software program used to connect to a server or other software over a network, such as a web browser like Chrome or Safari. Other examples of clients are apps and widgets on our smartphones.
Just go through the programs installed on your computer and think of the ones that connect to a server and/or operate over the internet. For me, I see an email client, HP Smart (printer), Zoom, DropBox, Google Chrome and Anki. Maybe VS Code, my software text editor, can be considered a client since I have it setup to communicate with GitHub servers? I’m not entirely sure.
A lot of stand-alone client software programs have a web-based counterpart. A couple advantages I see to locally installed clients versus web-browser applications are the potential to be used without a network connection and it’s easier access to resources on the device like files, images, microphone, camera etc.
“A server is a software or hardware device that accepts and responds to requests made over a network” — Computer Hope
The most common server scenario is receiving requests for web files from clients.
In a RESTful system, the client and server can function independently to the degree that changes to the code on one side do not affect the operation of the other side. This separation of concerns improves the flexibility and scalability of the code base.
“By using a REST interface, different clients hit the same REST endpoints, perform the same actions, and receive the same responses.” — codecademy
State and Statelessness
I first discovered the concept of ‘state’ in React, where data could be stored in one component, passed throughout the program and be altered. This data could be names, numbers, arrays, objects, function calls, variables, constants etc. Whatever data your program has when you’re looking at it, that is its’ ‘state’.
I also remember times when my function(s) didn’t set/reset the state properly and so I wasn’t getting the proper return data that I wanted (if any data came back at all). Yeah, if it wasn’t stored in state then the data is just forgotten and unattainable. Fun times debugging those and finding where the state has gone!
RESTful systems are stateless, “meaning that the server does not need to know anything about what state the client is in and vice versa”. — codecademy
Data doesn’t need to be held in memory. A prior request or operation doesn’t affect future computations. The reusability of a stateless system allows for actions to be repeated to get reliable responses.
Model-View-Controller (MVC) Framework
Separates an application into 3 components:
Model — here is where the object logic is held, for instance, what attributes will each iteration have
View — what is presented to the user or client; can also be interactive forms
Controller — the interface between the View and Model; handles user interaction which can update the state in a Model or change the data in the View
This isn’t an in-depth explanation of MVC. Just wanted to mention it as it may be useful to understand depending on how you want to code. Learning Ruby on Rails helped me to understand MVC.
CRUD Actions
These are the 4 basic types of actions a model in MVC should use. Or, in general, any program/application should be able to do.
Create — creates new object on server
Read — display list of all objects or displays the details of 1 specific object
Update — updates specific object on server and/or in backend database
Destroy — deletes specific object
This is a handy acronym to remind all developers to include these in their work.
HTTP Verbs
There are 4 HTTP verbs used in client requests.
(a resource aka a model from the MVC frameworks)
GET — retrieve a specific resource (by id) or a collection of resources
POST — create a new resource
PATCH or PUT — update a specific resource (by id)
DELETE — remove a specific resource by id
*PATCH & PUT are synonymous so either can be used and will function the same
*and yes, these HTTP Verbs need to be bolded
Routes
There are 7 routes with each related to 1 of the 4 CRUD actions and therefore uses 1 of the 4 HTTP verbs/methods. The table below shows them all with a template of their URL path.
*if your application is say using ‘Pizza’ objects 🍕, replace ‘object’ with ‘pizza’
*heads up, custom routes can be made but I won’t be going into that in this blog
These 7 route names will also directly correlate to the route method it invokes in the controller.
Ah! Good ol’ reliable, predictable and easy to follow naming conventions!
Conclusion
Let me try to walk you through the flow of all this now that we have a Client and Server, an MVC, 4 CRUD actions, 4 HTTP verbs/methods and 7 routes.
1/ The Model/Resource is ‘Pizza’. 🍕
2/ To get the details of a specific Resource to display in the View of the Client, we will use the ‘Show’ route.
3/ If you’re using the MVC framework, ‘Show’ will also be the name of the method you’ll use to determine what will be shown and how.
4/ ‘Show’ is a ‘Read’ action from CRUD.
5/ When fetching the details, the ‘GET’ HTTP method is used.
6/ Let’s say we want the information of the pizza with an ID of 1 in the database/Server.
7/ The URL Path will be something like: pizzawebsite.com/pizza/1
These naming conventions of RESTful routing allow everything to work in harmony. This process can be repeated to fetch other pizzas with different IDs.
