Adhering to the 7 RESTful Methods

Are you an organized developer who keeps codes simple and clean? Do you use Controllers properly? Do you adhere to the 7 RESTful Methods consistently?

If the majority of your answers to these questions is YES, then let me congratulate you for executing correct practices on M-V-C framework. However, if most of your answers are NO, you should change your habit. Messy codes are hard to understand and can give someone a terrible headache when debugging programming errors.

The Model–View–Controller Framework

In programming, a Controller is one of the main components of Model-View-Controller Framework or M-V-C Structure. Its primary purpose is to manage or direct the flow of data between Model and View to maintain efficiency and order. Developers work on various features: and as a result, Controllers could get polluted and filled by tons of stuff either due to the developer’s lazy habit when implementing a new feature, or lack of knowledge on how to use Controllers correctly.

But let’s be honest, putting “relevant” methods together in a single controller has great advantages; it gets things done faster compared to creating an entirely new controller class. Therefore, having sufficient knowledge of the 7 RESTful methods, a method introduced and defined in the year 2000 by Roy Fielding in his doctoral dissertation, would be beneficial when exploring and testing APIs because each method varies depending on its function. If you apply them to your work, it will save you time and effort. In fact, those methods will not only make your code easier to read for others and yourself, but it can also make the API implementation easier.

7 RESTful Methods

GET- returns a collection of resources

NEW-returns a form to create a new resource

SHOW-returns an existing resource

POST-saves a new resource to the database

EDIT-returns a form to edit an existing resource

PUT-updates an existing resource in the database

DELETE-deletes an existing resource in the database

Remember, the 7 RESTful methods are public by default and commonly used when browsing the web.For example, when you visit a website, you’re receiving a representation of the resource from either a GET, NEW, SHOW, or EDIT endpoints or methods of a website. And when you submit something to a website via form submissions, you’re sending the representation of the resource to either the POST, PUT, or DELETE endpoints or methods of a website.

Note: I am using MEAN stack in the following code examples, but feel free to follow along with any MVC framework of your choice.

To understand how it works, imagine that we have a Travel Expense Tracker App, so we’ll create a TravelsControllerfor that:

You know the drill. These requests should either return or process resources in specific ways. But what if we want to add an expense to a particular travel? Should we add a POST /travels/:id/add_expense url, and point it to anadd_expensemethod in TravelsController? How about canceling a travel expense? Or show which travels were canceled?

Here are some examples of methods you can add to your controller:

While it’s okay to add these methods in theTravelsController, remember the more methods you create on your controller, the messier it will get in the long run because you stray further from the initial public methods. A good way to manage these customized methods is to place them in their controllers.

In the above example, we’ve two methods that dealt with travel expenses. In this case, consider creating a new controller class and name it TravelExpensesController:

And as for showing all canceled travels, you have two options:

1.Implement filters for the GET method in TravelsController. It will be discussed in my next blog so stay connected!

2. Create a CanceledTravelsController.

For option 2, you can use the GET method to gather all the canceled travels as well as to handle actions related to processing canceled travels. By using this approach, you still adhere to the 7 RESTful methods. That’s also true for pending travels, and so on. It would be better to create a new folder to store all “travel” related controller files to organize multiple controllers of the same category.

But don’t get too excited! It’s not the only solution for bulky controllers. You don’t have to apply this approach in every possible scenario. If you plan on implementing new features, and you feel like the methods need to have its own controller, then you should probably do it.