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.
Related
I am quite perplexed over the use of Web Api in a MVC application being developed at my company.I recently joined the project and wondering why they are using this.The application uses JQuery AJAX functionality to pull data for each Tab in a MultiTab Page without refreshing it.
The application here is neither providing data service nor consuming any Web API service.This can be easily achieved without using REST verbs.It is directly connecting to database like a typical web application.
I am holding back myself to raise this question with the team since I haven't used Web API much but has a conceptual idea.
Am I missing something here ?
Microsoft's Web API MVC technology is typically used for external components to interact with the system - not generally a requirement for a standard MVC Web Application.
With that said, I'm not perfectly clear on the architecture. A few points of note:
jQuery AJAX is a perfectly valid (and usually preferred) method to retrieve information for tab pages - it provides a SPA (Single Page Application) "feel" to the site and generally improves performance all around. This does not mean that they're using a Web API
MVC is a framework used for many web applications, including Microsoft's Web API projects as well as ASP.NET MVC Web projects. The use of MVC doesn't mean that they're using a Web API.
A RESTful approach isn't just for Web APIs. Indeed, many find it a cleaner approach when using regular MVC Web Applications, as it tends to be more semantic to what actions are actually being performed (GET to get a view, POST to post data, DELETE, etc.) There's no real reason not to use REST verbs (which are actually just HTTP verbs, but called "REST" when we use them in a certain way). The use of HTTP verbs doesn't mean that we're using a Web API.
To conclude, The MVC Web API framework is it's own technology that's similar to MVC Web Applications, but more geared towards working with non-visual requests and responses, instead tailored to programmatic interfacing.
If this is indeed a Web API being used and not a case of MVC practices that you happen to be unfamiliar with, then yes, I think it's a good question to raise (at least from a technical standpoint - politically, maybe not, but we can't answer that for you).
A typical setup is to have multiple projects, one of which is a Web Application, which makes use of shared project(s) for domain/business classes and data persistence. Additionally, a Web API project is often used to provide access to the system for external components, but this is a separate "presentation layer" project from the aforementioned Web Application.
There may be cases where a Web API application is written as the core interface between the internal system and the rest of the outside world, where the MVC Web Application then interacts with the Web API, but this is a corner case that should only be done with specific reason, in my opinion (unless I misread, this seems to be the case you're stating?)
Using both MVC and WebAPI together in a ASP.NET Web application is quite common. Whilst you can provide HTML through WebAPI and you can provide JSON through MVC it's much cleaner to use the best technology for each.
WebAPI in particular lets you define an API once and then generates JSON, XML, ... for you based on the request.
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.
I'm developing an ASP.NET MVC 3 application. I need this application to make use of an API I also need to implement. The API should both be available from ASP.NET MVC controller actions and Ajax. Now it is quite easy to make an API using ASP.NET MVC, but is it possible to use this from other ASP.NET MVC website actions? I guess the WCF is quite easy to use as it is just a service reference.
Other users of the API could be Windows Phone and iPhone.
Update:
Many only sees the API as a place where you consume data, but what about the part where you want to execute commands or do stuff, like add customer or change foo?
You may want to check our new WCF web API that was announced at PDC. We recently released a big upgrade. WCF Web API is designed specifically for allowing you to expose APIs to a range of clients in a pure HTTP manner. It is lightweight, offers a nice configuration story (no configuration files) and also is much easier to test.
You can download the bits at wcf.codeplex.com. It includes various samples, and there is also a set of NuGet packs for getting you started. Search for webapi.all on NuGet.
The way I like to do this is with RESTful controller actions. You can return JSON and use your calls with JavaScript on your own site. Other websites would almost certainly understand JSON and so they'd be able to consume your API pretty easily. This is much easier to write and test than a heavy WCF layer.
Check out this question for some example REST frameworks for MVC:
ASP.NET MVC REST frameworks
One of the newer ways of accomplishing data feeds is using OData. Scott Hanselman has a great introduction to it in Creating an OData API for StackOverflow including XML and JSON in 30 minutes.
It allows you to even throw LINQ queries into your URLs to retrieve exactly the data you need.
Open Data Protocol (Official site)
Open Data Protocol (MSDN, Microsoft)
WCF JSON binding was really terrible last time I used it. WCF also comes with all sorts of crazy rules about streams and how you have to use [MessageBody] attributes for everything.
It was a real PITA to me.
I knew I've answered something like this before:
What is the best way to implement a RESTful architecture in .NET today?
I want to expose a service on my site that any users can call and get a JSON response. In the end, I want the users to be using this service as much as possible.
My site is created using the asp.net MVC framework and i was wondering whats the best way to do this...
I think most would say it's obvious to use a web service (*.asmx) that returns JSON format, but i know that I can just create a url that users can call and have it return JSON format as well (e.g: calling "http://mysite.com/GetList" would return JSON list). In asp.net, using the return Json() method.
What are the advantages/disadvantages doing it this way vs. a Web Service which is specifically intended for this ?
I don't know that most would say use a .asmx web service. Personally I haven't made a .asmx web service in a while and I would go for the MVC approach. The only things I'd be worried about would be:
future changes to the data, url, and/or parameters passed in.
Making the controller too big or cluttered, in which case you could create a separate API controller.
To me the advantages are that it's more consistent with the rest of your app, it's simple and easy to work with, and there's not much to configure.
A web service would expose a WSDL.