I am an MVC.NET developer but never used API web service before in an MVC project.
I just want to know like for WCF services we use different project in the application usually. Likewise, what is best practice likewise for web API services and how they work with proxy design patterns extra?
In my current application I am using WCF services but I am keen to learn if API web service can replace it and how?
yes , you can replace with API service.
For your project structure , you can refer below link content.
Implement ASP.Net Web API in ASP.Net MVC 5
http://www.c-sharpcorner.com/UploadFile/4b0136/implement-Asp-Net-web-api-2-in-Asp-Net-mvc-5/
Related
We are going to build a web project which will potentially use Mobile app as well in the future. So we decide to consume all data works via Web Api. As a start, we will use seperate MVC project. In traditional way, I use Identity2 for authentatication issues and all Controllers of MVC project is secured by [Autherize] attribute. In our scenario, we want to give this job to Web Api project. MVC project will be only consumer of Web Api project. So I am wondering how I can login to Web Api project from MVC project and secure controllers via Web Api. Do you have any suggestions or sample?
I did some research around but I have some doubts still about following topic...
I have Silverlight/RIA Services project that needs to have ASP.NET MVC look as well as WebAPI for some different clients.
So my question is following
Can we use somehow RIA Services with ASP.NET MVC 5?
And if not what is a painless way to represent all existing logic in ASP.NET MVC?
Thank you!
Ria services have nothing to do with look and feel.
A Silverlight app or a non plugin, which uses RIA services can be hosted in a web page created using ASP.Net.
Can we use somehow RIA Services with ASP.NET MVC 5?
Yes.
RIA services which could be used by an asp.net backend would not gain the benefit of RIA services because changes made in the backend end are not generated forward to an application such as a Silverlight plugin. It just becomes another way of accessing data.
I am developing an MVC5 application and use Entity Framewerok 6 code first on this. Now we we will also develop an android application that will interact with the MVC application (CRUD operations) by using the web services. At this stage I want to be clarified about the issues below:
1) I think WebAPI is better option for us as we use the services on android apps. What do you suggest?
2) In order to integrate WebAPI to an MVC project, which changes should be made? On the other hand, can we use the same controller and data layer methods (i.e. SaveChanges, etc.) by making some modifications i.e. inheritance? Or do we have to create a seperate methods for web services? Could you give an example by code?
3) Does integrating WebAPI to the MVC project affect the MVC project's abilities or methods? I mean that is there any disadvantage integrating WebAPI to an MVC project?
Any help would be appreciated.
1) That's a good idea. Web API is easy to implement and consume
2) You don't need to make changes to intergate Web API in your application: just start using it. As you want to expose CRUD operations from EF a good idea would be to implement ODATA services. Or use something like Breeze (depending on how you want to consume the services). See "MVC and Web API" bwelow
3) Web API doesn't affect at all the MVC part, unless you make a mistake setting the routes. Although they run in the same host, they work completely independent of each other.
MVC and Web API
Unless you need to do something special, like exposing Web API in a different URL or "domain name", MVC and Web API are implemented in the same web application project. To start using Web API in your MVC project simply add a new controller. Perhaps you'll have to include also the WEB API route configuration, and some other Web API configuration.
If you want to expose the EF model throug Web API you simply have to follow the instructions in the link to create an ODATA controller, which will expose the EF model as a RESTful service, allowing you to execute the CRUD operations to the EF model through URLs.
NOTE: What you want to do is a very frequesnt pattern in MVC applications: MVC is used for generating the views, and Web API fos exposing functionalities that can be easily consumed from the views usin Javascript + AJAX. Don't be afraid to use it. You'll find no problems at all
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.