Could someone please help me with the below question??
Difference between MVC Action Methods and Web API Action Methods
The only difference I know, was the return types of both methods.
MVC Action method Return Type:
ActionResult (It is abstract class) and all the derived classes.
Web API action Method return types:
Void
Primitive Type/Complex Type
HttpResponseMessage
IHttpActionResult
Appreciate the further differences between those two. Thank you.
Both MVC and Web API action can return ActionResult or IActionResult type objects. So that is no longer a difference.
Here are few differences if you are still looking for some:
In Web API, a request is mapped to an actions based on the HTTP verbs. Not for MVC
Based on the Accept header in the request Web API returns data in requested format (e.g. XML or JSON)
With Web API you can create RESTful services based on Dotnet Framework. But cannot with MVC
With MVC we can build Web application that can return both data and views but Web API is for sending data only
There are many differences between MVC and Web API, including:
We can use the MVC for developing the Web application that replies as both data and views but the Web API is used for generating the HTTP services that replies only as data.
In the Web API the request performs tracing with the actions depending on the HTTP services but the MVC request performs tracing with the action name.
The Web API returns the data in various formats, such as JSON, XML and other format based on the accept header of the request. But the MVC returns the data in the JSON format by using JSONResult.
The Web API supports content negotiation, self hosting. All these are not supported by the MVC.
The Web API includes the various features of the MVC, such as routing, model binding but these features are different and are defined in the "System.Web.Http" assembly.
And the MVC features are defined in the " System.Web.Mvc" assembly.
The Web API helps the creation of RESTful services over the .Net Framework but the MVC does not support.
Related
It's more a structural question than a technical one.
I made a classical Web App with ASP.NET MVC.
I works well, the server responds with HTML when I send him an URL. Ok.
I now want to make a mobile application (Android) to access the same data.
Maybe there is a way to use the controller's methods which already return the objects I'll need.
So the question:
Is there a simple way to make a REST API from a ASP.NET MVC WebAPP?
Once again, I think that the controller's method will be pretty much the same. It just has to not return HTML but XML for instance.
I'm a newbie in the Web services technologies.
Add webapi project to your solution
Configure web api controllers
Reuse MVVC classes to access database
Return necessary data - webapi will return it in json and in xml (depends how client will consume it)
The title really sums up my question. I have used both technologies but I am uncertain as to what one offers that is substantially different than the other. In essence:
What criteria and/or guidance should one consider when selecting ASP MVC or Web API when designing a restful web application?
Purpose
ASP.NET MVC is focused on making output of HTML easy. ASP.NET Web API is focused on making output of raw data easy.
In the WebForms world, ASP.NET MVC would be equivalent to .aspx pages and ASP.NET Web API would be .asmx.
Although nothing is impossible
While it's possible to make Web API output HTML and MVC output raw data, you will need additional work. For example, making additional classes to handle text/html during content negotiation in Web API, or adding logic to handle OData queries in MVC.
Assumptions
The default assumption for both MVC and Web API are different too. MVC by default assumes user submitted data can come from multiple sources, be it in the query string or in the form.
Web API by default assumes that primitive type comes from query string and non-primitive types comes from the form. It also assumes that you would only want to read the form body once, without caching, to have lower memory usage and better performance.
Going against the defaults requires additional work, that to me, does not make sense at all.
EDIT:
Also, GET AJAX request is blocked by MVC's JsonResult by default to prevent CSRF, while Web API allows GET AJAX request by default.
Update for MVC 6
MVC 6 unifies MVC and Web API and allows you to return ViewResult like in MVC or object like in Web API, and the framework will take care of content negotiation, creating the HTML, JSON or XML for you. Lower memory usage also arrives in MVC, by using its custom pipeline instead of what is provided by System.Web.
So going forward, there's no distinction between the MVC and Web API.
How does MVC and web API work together in an application?
Are you supposed to use javascript binding (with knockout.js and ajax calls) and just use MVC for the actual container page?
Or do you call web API from the MVC controller (like a WCF service layer)?
The integration of MVC and web API just isn't clear to me.
Should I use Web API if I regulary require HTML to be returned (i.e. I want to work with Partials)?
I'd like to use web API so I can scale my app though (return HTML from one side, but remain with an API that can return/process XML)!
Thanks for clearing it up :)
This picture below from the link explains clearly how MVC and Web Api work together:
Technically, you can call from MVC to Web API, but it is not really the best practice since:
Calling from MVC to Web API will across the network (distribution), this makes your application more complex.
Web Api is REST Api, it is not like WCF which is heavily SOAP Api (although WCF support REST Api). So, from JavaScript you can call the Web Api easier using ajax.
Here's how I set up my latest MVC and Web API application: There's the regular model layer (*M*VC) and I have created a service layer for the business rules. The controllers of my MVC application call the service layer to process data from and to the views.
My Web API application is a external interface to the methods on the service layer, therefore both the controllers on the MVC application and on the Web API application call the service layer. I hope this helps.
I've seen a lot of arguments for why moving from WCF to Web API is a good move, but I haven't seen much on migrating from a controller with JsonResult actions to a Web API project. Can anyone provide the main benefits on switching to the Web API platform, or does it make sense to not migrate and stay on MVC3?
WebAPI provides a lot of stuff out of the box that you don't get with a standard JsonResult. For instance, WebAPI is aware of the content types the caller expects, and can return Json, or XML or other types as requested.
Another nice feature is that WebAPI is oData aware, and you can use standard oData HTTP commands to filter and perform other actions, all without your code needing to do anything specific.
WebAPI has tons of nifty features that make a nice webservice, without the overhead of a full WCF service or asmx.
If you're happy with a JsonResult though, there's no need to rewrite it.
I have recently discovered OData & the new WCF Web APi library on codeplex. The web api allows me to expose results as IQueryable, which allows me to expose URL's in the OData format. Myn question is what is the difference between this and a regular OData Service, I read the following blog post http://phejndorf.wordpress.com/2011/07/15/wcf-web-api-odata-format-doesnt-mean-odata-service/ but I am unsure what the OP means.
Thanks
The WCF Web API supports adding a [QueryComposition] attribute to a function so you can use the OData $filter=.. style of filtering data on the server and sending only a subset back to the client.
With OData, I should say WCF Data Services, there is much more that just querying. You can do all of the CRUD operations. It also means you are using the OData, is an AtomPub superset, protocol where with WCF Web API you do whatever you like. OData is actually a hypermedia format that contains metada, relations etc.