I have a MVC web application and I make some ajax calls from the client to get back json data. Right now I just use MVC Action methods to return this data. I was wondering if I should be using the ASP.Net Web Api for these.
I understand that if I was building a REST solution I should be using it.
But in this case would it be justified to add the extra complexity? Is there any speed gain? I don't really need the Content Negotiation feature or the OData Support.
According to the post here (and the benchmark it references), Web API is a bit faster. Web api performance?
ASP.net Web api support both JSON and xml. Web Api is for implement rest web service on top of MVC application. It would add extra complexity for the application but you implement web api related method in separate controller.
Rest web services are usually faster than Normal SOAP web services.
In your case if your clients are just a web client no need to implement web services. But If you need to share service for different client (widows applications, windows services, third party applications) implement rest service using web API
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.
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 developed a website in ASP.NET MVC 4 using NHibernate, now I need to perform an integration with the site using Windows Forms.
How can I perform authentication system using the same users?
What technology should I use? Web API, SOAP or Rest?
Thanks!
Small clarification of terms : REST is an architectural style, SOAP is a protocol for exchanging information, and Web API is a framework to build HTTP Services.
The stock answer for questions like this is "It depends"
Before you continue with a technology selection, currently is your method for authenticating users separated properly from your business/presentation logic?
If that is the case, being that you are using MVC 4, Web API may be the path of least resistance, you can put all of the functionality that requires authentication behind Web API calls. And your controllers will call them. Once that is done, a Windows forms app can consume the data in a similar way.
I saw that ASP.Net MVC4 WebApi exposes services as a Rest ones.
But what is actually the difference between normal Rest and ASP.Net MVC4 WebApi?
I'm not sure what you mean by normal Rest.
REST is a paradigm.
HTTP is a protocol that follows that paradigm.
ASP.NET Web API allows developers to write ASP.NET applications that can be accessed via HTTP and adhere to the REST paradigm. While you could create a REST API without Web API, Web API provides a ton of features that will remove a lot of the pain associated with creating a truly RESTful API in ASP.NET.
apigee has many great resources for REST API best practicies.
Are you asking about the general REST standard or the way that REST has been done traditionally on the Microsoft platform prior to the MVC4 Web API? I am thinking you are approaching this as the second one.
The updated approach in MVC4 gives you more REST capabilities without the WCF model. Here is a recent post on the subject: http://mattmilner.com/Milner/Blog/post/2012/02/28/WebAPI-or-WCF.aspx.
What is the difference between making calls to mvc controller methods and WCF WEB API Rest Service Calls?
I can create an mvc controller post method that will allow me to execute any code i need.
I can also create a WCF Web API REST Service with MVC.
What is the difference between these two approaches to accessing data ?
More specifically what are the advantages of utilizing WCF in this scenario ?
WCF Web API handles XML and JSON out of the box whereas you'll have to create your XML and JSON "by hand" (read: using the Serializers) when using MVC - this is only one of the benefits of WCF Web API over MVC.
Another one is the level of separation WCF Web API offers e.g. implementing your service logic vs. content negotiation.
Yet you can easily use IoC containers and unit test your APIs being created using WCF Web API.
WCF Web API mainly has been created to build ReSTful API's whereas MVC just allows it to create them too - thus with WCF Web API you'll feel more comfortable creating ReST APIs.
If you're planning to start a project from scratch as an Web (ReST) Api, you should start with WCF Web API.
If you're planning to start with a Website that also offers ReSTful Services, you should suggest MVC.
You should also regard this tweet from Glenn Block.
You could accomplish a typical REST API with either one.
Usually the issue boils down to (1) what specific features you need and (2) what technology you are more familiar with.
There are some features of WCF that are really neat and not available in MVC (like binary serializations, the ability to host without IIS, et cetera) but those are not typically requirements in a REST API.
Overall I would say:
If you have an WCF implementation already in place and want to expose it as a REST API go for it with WCF.
If you already have an MVC site and want to expose it as a REST API stick with MVC.