Difference between MVC & Web APIs
Model View Controller |
Web API |
|---|---|
|
MVC is used for developing Web applications that reply to both data and views |
Web API is used for generating HTTP services that reply only as data. |
|
When receiving the request, MVC performs tracing based on the action name. |
When receiving the request, Web API performs tracing based on HTTP requests. |
|
By using JSONResult, MVC returns the data in the JSON format |
Depending on the accepted header of the request, The Web API returns data in JSON, XML, and different formats |
|
“System.Web.MVC” assembly has all defined features of MVC. |
“System.Web.Http” assembly has all features of MVC but does not have routing, and model binding which are exclusive to Web API. |
|
MVC does not either support content negotiation or self-hosting. |
Web API supports content negotiation, self-hosting |
|
MVC controller is extremely heavy and we can see the number of interfaces the code uses. |
Web API has a lighter controller and it can distinguish requests by their passed parameters |
|
MVC controller cant support API views as it is tightly coupled with the views. |
Web API can be hosted anywhere without worrying about the views. |
| Popular MVC Frameworks are Ruby on Rails, Django, CherryPy, Spring MVC, Catalyst, etc. | Popular API Examples are Google Maps API, YouTube API, Twitter API, etc. |
Differences between Web API and MVC
In this article, we will see what is Web API & MVC, their features & components, along with knowing their advantages & disadvantages, finally, will see the difference between them.
The Model View Controller (MVC) is part of an architecture pattern that separates the application into 3 major Logical components that consist of a data model that contains only the pure application data, without containing any logic that describes how to present the data to a user. The Presentation(view) signifies the model’s data to the user. The view knows how to access the model’s data, but it does not know what this data means or what the user can do to manipulate it. The final part is the controller that exists between the view and the model. It listens to events triggered by the view (or another external source) and executes the appropriate reaction to these events. In most cases, the reaction is to call a method on the model. It is basically responsible for managing the query string values and transferring the result values to the models.