MVC and REST API Services Overview

REST API SERVICES 

Where does data come from? It’s the servers from where we get the data. Client communicates with server to extract information. In a bookmyshow app all the time and show times are being updated on a daily basis with respect to movies, events, and everything in between, and the data is from web server. A client request a server from API and server will send back the response to the client, in the form of a html webpage.

You won’t expect HTML page as a result, so the data will have to be returned in either JSON format of XML format. Both of these formats have proper structures in which the data is represented. How do we avoid looking at tons of methods? The only problem is we have to do a lot of work to get certain data and request for the data to be returned and so on. Imagine requesting for data and looking into many many methods. To avoid such methods, the REST API creates object and sends the values of the object in response to the client’s request.

REST saiys create an object on server side, which is Representational State Transfer. REST API creates an object of a request, and then nsearches for data in server for client request. Now if you obsere, you’re creating an object and we have the values of the object sent to the client which is the state of the object that is sent to the client. We no longer have to generate a new object. IT is an architectural style as well as an approach for communications purpose that is often used for various web services development, known as the “language of the internet”.  REST is simpler than SOAP, documentation, and error messages.

6 principles are stateless client server uniform interface cacheable layer system code on demand.

There are uniform interface separating clients from servers. In order to provide better performance, the applications are cacheable. The layer system architecture allows an application to be more stable and enable load balancing/shared caching to promote stability. Finally the core on demand permits a client’s code to be extended and simplifies the client by creating a smart application that doesn’t rely on its own structure.

A lot of applications are CRUD, or create read update delete. Resource is what we want to do. We can mention parameters through a slash “/”.

POST GET PUT and DELETE are all of the HTTP methods. Nodemon prevents the nodeJS server from restarting every time changes are made. Automatically nodemon will detect changes. The server will have to be valid for the client to send request to the server. In your controller code look for the Get Put Post Delete and Update. Request will be sent from the client side, while the response is sent from the server side. Look at the localhost url and see how to parse this url. For each request and url then we can edit the code based on the request parameters inside of the REST API.

You can use POSTMAN to send the request to the servers. You can click on the plus button on the POSTMan, then you can mention the url and you can choose the GET method along other methods (this is also used to test REST API functionality in code deployments.). Once you click on send, then you get output. This is how you can get data instead of the website. We can also have a validation server that validates information. If it’s validated push the data. Else show an error. We can see the body on the bottom accordingly.

PUT method is used to update an existing resource. To update a resource we update a specific customer’s name. Now let’s go over the functions.

MVC

This isn’t specific for one programming language. It’s depending mainly on how you organize your code. Moving to the animation area, we have seen MVC hundreds of times. Let’s say at a restaurant you don’t make a food by yourself. You wait for a waiter to come inside of a restaurant. Waiter doesn’t prepare the food. Food is prepared by the cook. Waiter will tell the cook what to prepare. 

However, cook cannot prepare food magically, he needs all the ingredients so there will be a fridge as a result and cook will hand over the food to the waiter. Now your food is ready. But now this is your entire model view controller. View you is a view. The waiter is a controller. The cook is a model. The fridge is the data. It’s a design pattern and the way to arrange a code and It’s accessible everywhere. We are trying to reduce the dependency so that if some data Is passed, then there should not be dependency between the codes. 

At some point where there is a small task, then MVC isn’t worth it otherwise if we are working for a huge application then MVC would be worth it. The model is not the data. Again, the model is not the same thing as the data, the data is completely separate, which you fetch from API request. The model should be the guy that cook up the data and controller takes the data filter the request. 

For example if you look for top 10 wonders, if you are looking for ancient wonders then controller filter that data and the view arrange this data. This is a generalized way to write the code, to separate the data dependencies.