A Short Introduction to Seven Restful Routes: Verbs to control CRUD actions on HTTP requests
If you are not familiar with the concept it may sound like a movie title parodying The Magnificent Seven or Seven Samurai.
So what are we talking about when we say Seven RESTFUL ROUTES and why do we need them?
To understand the real value of RESTful routes, let’s go back in time when the Internet was RESTless. Remember the old days where we would look at a ridiculously long URL on Netscape Navigator (or another browser/client) and have little to no chance to navigate through or change the domain path? In those dark ages(before 2000) there was no standard on how to design an API or use one on web applications. Most developers had to deal with protocols like SOAP (Simple Object Access Protocol) which were complex to build, manage, and hard to debug.
Dealing with SOAP wasn’t the only issue. Application routes were dictated by the developer. At first, this may not seem like a big deal. Except that it means every application had a different naming structure for routes. Below you can find an example to see how the team standings page on NBA.com was displayed in 1999. Thanks to amazing web apps like http://oldweb.today/ you can go back in time and check how the “old web” was in action.)
In 2000, Roy Fielding came up with a new concept, REST, in his Ph.D. dissertation “Architectural Styles and the Design of Network-based Software Architectures” at UC IRVINE. Briefly, REST ( Representation State Transfer) is an architectural style for defining our routes, providing a uniform way of identifying URL’s and mapping them to an MVC application. The first ones to be interested in the phenomenon were the e-commerce giants, eBay followed by Amazon and the REST is history (pun intended).
To extremely simplify the concept — REST is a naming structure that encompasses HTTP actions. The basic premise is — instead of relying exclusively on the URL to indicate what webpage you want to go to it is a combination of a VERB and URL. This way, the same URL, when used with a different verb, will get you to a different page.
This brings a level of standardization to development, makes you conscious of your controllers, makes for cleaner, shorter URL paths for users, and is particularly adapted to CRUD applications in a conventional pattern. Managing routes yourself can be frustrating and you may face unexpected problems as the application grows.
By using A RESTful route, we can work with a route that provides a mapping between HTTP verbs (get, post, put, delete, patch) to controller CRUD actions (create, read, update, delete) easily.
Let’s first review the 5 HTTP VERBS
-GET requests a representation of the specified resource. Requests using GET should only retrieve data.
-POST is used to submit an entity to the specified resource, often causing a change in state or side effects on the server.
-PUT replaces all current representations of the target resource with the request payload.
-PATCH is used to apply partial modifications to a resource.
-DELETE deletes the specified resource.
In my Sinatra Crud Project, I am working on a web app that you can save information related to your graphic novels/comics collection. So let’s take comics as an example to analyze different restful route patterns and see how we would build controller actions to create a new comic book, using the HTTP verbs above.
What is the Difference Between PUT and PATCH Requests??
When I first started working on my Sinatra project, understanding the difference between PUT and PATCH requests was somehow challenging for me, therefore, I wanted to have a closer look into the differences and the use cases for these two HTTP verbs.
As we can see above PUT and PATCH are HTTP verbs used for updating a resource based on its ID in the URL. So what is the main difference between PUT and PATCH?
The main difference is that the PUT method overwrites a resource with a completely new body, and cannot be reused to do partial changes whereas the PATCH method is considered a set of instructions on how to modify certain elements of a resource.
Suppose we have a hash with the keys and values below in our resource
Well, that doesn't look right. Who is Tobby Stark?
If we want to change the first name to “Tony” then we send a PATCH request to only send the first name to update. With a PUT request, we have to send all values again.
One important thing to keep in mind is — these HTTP verbs are just blueprints for our convenience and if our intent of use is different than the actions listed above, the best way would be to create our own routes.
Happy coding and please let me know if you have any comments or suggestions!
