A Short Introduction to Seven Restful Routes and a Closer Look at Put/ Patch HTTP Verbs

While working on my Sinatra CRUD application project at Flatiron School, one of the most important, if not the most, aspects of the project was to get a solid understanding of the 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?

Image for post
Image for post

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.

Image for post
Image for post

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.)

Image for post
Image for post
“/standings/team-record_comparision/conferenceNEW_Std_Cng.html what a wonderful URL”!

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).

Image for post
Image for post

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.

Image for post
Image for post

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

Image for post
Image for post

Well, that doesn't look right. Who is Tobby Stark?

Image for post
Image for post
Well, I don’t know you might want to change it on your code!!

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 creating our own routes.

Writing this blog post really helped me to understand the basics of RESTful routes and differences between post and patch verbs for my project and I hope this article can help my fellow students or coding enthusiasts for a better understanding of the SEVEN RESTFUL ROUTES.

Written by

Software Engineer & Marketing Strategist -experience with top tech. companies inc. Cisco, Citrix, Hitachi, Apple, Facebook-former NBA writer & guitarist

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store