|
I'm building an ASP.NET MVC application that is client-script heavy, it will use JSON and jQuery to manipulate the DOM. My understanding is both Web API Controller and MVC Controller can return JSON. Given my scenario, should I use a Web API Controller or an MVC Controller? |
|||||
|
|
Web API Controllers can be created and hosted in any ASP.NET Application, not just MVC applications. Thus, an obvious reason to create a Web API is if you do not have an MVC front-end (e.g. classic, RESTful web-services hosted by your company/organization.) MVC Controllers typically rely on the MVC Framework, if you look at default templates and most of the work done by the community and your peers you will notice that almost all MVC Controllers are implemented with the View in mind. Personally, I use MVC Controllers when I intend to respond with a View(), and I'll use a Web API for anything that isn't dependent on a particular view. There are caveats, of course, but generally speaking if you don't require the Model Binding behavior of MVC, your service is data-centric, and operations are Data-centric (e.g. CRUD operations) then you likely want a 'Web API Controller' instead of a 'Model-View Controller'. Conversely, if your operations are View-centric (e.g. delivering a user admin page to the user), or you need MVC's Model Binding to generate 'ajax partials' (very unlikely), then you will want an MVC Controller instead. Personally, I use Web API controllers for driving JSON-based RESTful clients, I use MVC controllers for handling basic browser routing and delivery of the SPA. |
||||
|
|
|
WebAPI is for making an API. If you want someone to be able to consume your API in XML, JSON, etc. You can make a web api. In your case you only need to talk to client in JSON. Even though your website is mostly client script driven you would still be using ASP.NET MVC Controller right? And since you may have already logically divided your controllers based on entities then it make sense to add those json serving methods in it as opposed to making another class specifically for web api. So for your particular situation (if i understand correctly), I would stick with Controllers. |
|||||||||||||
|
|
The answer boils down to separation of concerns, fasten the creation of services and to rely on convention rather than configuration. Controllers main responsibility is to work as a coordinator between view and your model but where as API's main responsibility is to work on data. In the case of API's conventions make it really easy to perform CRUD operations. Below is the mapping between CRUD operation and HTTP actions
So with API's you do not have to create separate actions and attribute them with HTTP actions. |
||||
|
|
|
The best reason for use of web.API is when you are sure you don't need to return views like mvc can do. Web.API main purpose is sending back data. Sending back a view is something different but if you use plain html with JavaScript for that purpose like you do with angular then web.API is a perfect fit. |
|||||
|
|
The only concern I have with ApiController is that it is site-based not area-based. One site can only have one apicontroller subfolder for you to name your controller methods. There are situations you might want to duplicate controller name in different areas : domain.com/api/area1/controller1/ domain.com/api/area2/controller1/ I remember there are some custom code settings to be able to do this but it does not work by default. |
|||||||||
|
|
When I develop small MVC applications I use the controllers to divide application parts in Subsystems. So I look what are the subsystem parts of my program. Let say I have User functions and SubSystemA, SubSystemB etc. then I put those in seperate Controllers. So UserController, SubSystemAController and SubSystemB controller. I dont use repositories then because its a small system and thats the perfect fit. In those Controllers I mix Actions that return both View and Json data. Because a Controller can return View and Json data thats allright. No need for WebApi then. I think whats already said the main reason for WebApi is that you can use it for other things then Mvc. My goal is Always to use less not more. If I would use WebApi that would add another way of implementing code while it does not offer much more. The same thing counts with Script libraries. I use jQuery, jQueryUI, jqGrid and select2. Dont overengineer if its not necessary. |
|||||||||
|
