I am new to ASP.NET MVC and Web API and trying to get the basics. AFAIK, we have project templates in VS 2013, named as MVC, Web API and Both of them together.
I have gone through the tutorials and learned that we can make an API by using MVC alone as well as with Web API Template.
So, What are the differences between these, based on Architecture and Usage?
Basically, a Web API controller is an MVC controller, which uses HttpMessageResponse as the base type of its response, instead of ActionResponse. They are the same in most other respects. The main difference between the project types is that the MVC Application project type adds web specific things like default CSS, JavaScript files and other resources needed for a web site, which are not needed for an API.
MVC is used for creating web sites. In this case Controllers usually return a View (i.e. HTML response) to browser requests. Web APIs on the other hand are usually made to be consumed by other applications. If you want to allow other applications to access your data / functionality, you can create a Web API to facilitate this access. For example, Facebook has an API in order to allow App developers to access information about users using the App. Web APIs don't have to be for public consumption. You can also create an API to support your own applications. For example, we created a Web API to support the AJAX functionality of our MVC web site.
Microsoft changed the way they present the different templates. Now instead of using different templates for different project types, they encourage developers to mix ASP.NET technologies inside the same project as needed. Microsoft calls this vNext.
UPDATE: For ASP.NET Core, Web API has been integrated into the MVC 6 project type and the ApiController class is consolidated into the Controller class. Further details at: https://wildermuth.com/2016/05/10/Writing-API-Controllers-in-ASP-NET-MVC-6
My two cents...
In ASP.Net MVC – the MVC’s Controller decides what should be the View - i.e., the controller decides what the user should “see” (based on the current scenario or context), when they make a request.
In ASP.Net Web Forms, the ASPX pages decides what the user should “see” when they make a request.
But in Web API, there is no control/power to any of the Web API’s features to decide what the user should “see” when they make a request.
Web API is NOT a technology tied up with websites only. It can be used for multiple purposes – not only websites. So it doesn't know the meaning of rendering
Further Reading
Planning Web Solutions Today: Web Forms, ASP.NET MVC, Web API, and OWIN.
WCF or ASP.NET Web APIs? My two cents on the subject
The Next Generation of .NET – ASP.NET vNext
Getting Started with ASP.NET MVC 6
MVC controller derived from controller class. In Mvc you can returns views. Mvc achitecture uses to create an application. However Web apis are used to provide data to various application.
Web Api drives from Api controller and it doesn't return view.
Note: You can also create Web Api from MVC controller but you need to return result as JsonResult or other web api supported return types.
In addition to answers already provided here, its worth noting any controller which inherits from ApiController and having an action with Http verb POST can only have one [FromBody] input parameter. If using a MVC controller (deriving from 'Controller') you can have many post input parameters.
Related
I have an ASP.NET Core (.NET Core 2.2) app structured with the following projects:
API: this is meant to represent a WebAPI (with controllers inheriting ControllerBase)
Services: This contains services which the API controllers utilize to access the database, etc
Database: This contains the usual DB repositories, which the services layer utilize to access the database
Now, I want to add a UI that talks to the API (the MVC part pre-.NET-core). How is that accomplished with .NET Core, where MVC and WebAPI are one of the same thing? Should MVC controllers/models/views be part of the API? Should it instead be a new project that listens on a different port? How does authentication fit in for both (e.g. APIs usually have some token-based authentication, UI apps usually have username/password authentication)? Should the WebAPI and MVC portions share the same authentication like ASP.NET Identity? Wouldn't that tightly couple the two if they use the same database?
Is there some kind of Microsoft or community suggested convention/documentation for how to structure such projects?
How is that accomplished with .NET Core, where MVC and WebAPI are one of the same thing?
In dotnet core MVC and WebAPI can be present in the same project. Everything application is like a console application. You can add MVC services to startup class to make it an MVC application.
Should MVC controllers/models/views be part of the API?
Its better to have different controllers for MVC and WebAPI related functions separately while keeping them in the same folder.
Models - They can be reused for both mvc and webapi. Same for view models and DTOs.
Views - Just for MVC, webapi does not require views.
Should it instead be a new project that listens on a different port?
Yes, you can create a different project for webapi and MVC.
How does authentication fit in for both (e.g. APIs usually have some token-based authentication, UI apps usually have username/password authentication)?
If you use token-based authentication then both web API and MVC will be able to use.
Should the WebAPI and MVC portions share the same authentication like ASP.NET Identity? Wouldn't that tightly couple the two if they use the same database?
If you use ASP.Net Identity with identity server then both MVC and webapi will be able to share the same authentication mechanism without tightly coupling.
I think that you are a bit confused about WebAPI compared to MVC.
You can see WebAPI as simple web services answering http request with data (whatever the data is, it could even include javascript or assets).
EDIT:
So sending "UI" informations is definetly a part of your API and Service project.
On API you will need to create dedicated controller(s) to send back your "UI" part(s).
On Service you will need to create dedicated service(s) to fetch the "UI" informations (their is many way to do this, using Ressources, fetching data on Cloud, etc)
EDIT2:
But nothing prevent you from creating an entirely different solution for UI parts. If you chose WebAPI again, you will still need to enforce the previously mentioned API/Service logic. It's up to you to chose whatever you feel confortable with.
The answer to your question is mostly, "it depends on your tastes" but in my opinion...
Unless you are planning on exposing the API to other applications, keep the API controllers in the same application that hosts the MVC controllers (or Razor Page). When I have both MVC controllers and API controllers I put them under separate folders. I think this is OK, because your controllers should be very thin. I generally put all the business logic (including any necessary data access) in services that are built in a separate class library.
You only add an API if you actually need it.
Do you plan to expose anything to another app?
If all you want is a UI which interacts with a database then don't bother, use the services to retrieve the data, called them from the MVC controllers and skip the API part completely.
You don't need an API for such a limited use case. An API introduces a host of other things to consider, like authentication and security.
Don't complicate things when you don't need to.
I've never used traditional ASP.NET MVC and started with Nancyfx. I'm considering making the switch to ASP.NET MVC + Web API but have some general questions.
I think I may have been spoiled with Nancyfx but I have some real problems and concerns with it which is why I'm not sure on it for my rewrite. The main problem is the load times. I understand it compiles the Razor views upon first load which extends the load times but there are bugs that cause it to not work (known issues). I've implemented a work-around but I've read that ASP.NET MVC can pre-compile to avoid this situation (Nancyfx cannot).
Doing some research with ASP.NET MVC + Web API it seems the Web API is for the restful endpoints while the ASP.NET MVC is for serving the pages. As you know, Nancyfx combines these two technologies into one which is what is really nice. Am I correct about this or is there a way around to make ASP.NET MVC serve the Razor pages plus serve the JSON/XML requests depending on the request type?
I do not really care to use ASP.NET core to be honest because my application integrates heavily into Active Directory, Microsoft Exchange and other Windows application that are not on other platforms. Someone wanting to deploy it on a Linux server is kind of pointless IMO for what I'm doing.
To put it simply, ASP.NET MVC offers you two controller base classes: Controller and ApiController. You inherit from the Controller class if you want to create view-based controller actions and you inherit from ApiController if you want to create API actions. On the other hand, in ASP.NET Core, you can use the same controller infrastructure to deliver views as well as REST APIs. You can always combine .NET Framework and ASP.NET Core. However, .NET + ASP.NET Core solution works only on Windows about which you apparently have no problem.
I have an ASP.NET Core Web API application that is separate from my ASP.NET Core MVC application (UI). I didn't want to combine them for several reasons since in the future many different clients might need to access the API.
The MVC application makes calls to the API two different ways:
1. Using System.Net.HttpClient in the MVC controllers to populate the View Models.
2. When making jQuery AJAX calls I figured it would be best to directly call the API. (Note: I enabled CORS to allow calls from the MVC application). This would be the same thing as an Angular client making calls directly to the API.
My questions:
Is what I am doing pretty common making calls to the API directly from the client with jQuery and additionally System.Net.HttpClient in the Controllers when not using AJAX and just loading the view data. Should the AJAX calls go to the MVC controller first then let them MVC controller make a DELETE request using System.Net.HttpClient so I am never directly calling the API from the client?
What would the security concerns be? I am a bit nervous calling the API directly from jQuery. I feel like anyone can pretent they are localhost:6000 (my MVC port) and make a DELETE request to localhost:6001/api/users/1 (my API port).
You absolutely correct to be concerned about this. You should be securing your application from this making sure any requests to access these API methods are authorized.
I recommend reading 10 Points to Secure Your ASP.NET MVC Applications. for an overview on how to protect your application from this kind of attack and several other common security vulnerabilities.
I am new to ASP.NET MVC and Web API and trying to get the basics. AFAIK, we have project templates in VS 2013, named as MVC, Web API and Both of them together.
I have gone through the tutorials and learned that we can make an API by using MVC alone as well as with Web API Template.
So, What are the differences between these, based on Architecture and Usage?
Basically, a Web API controller is an MVC controller, which uses HttpMessageResponse as the base type of its response, instead of ActionResponse. They are the same in most other respects. The main difference between the project types is that the MVC Application project type adds web specific things like default CSS, JavaScript files and other resources needed for a web site, which are not needed for an API.
MVC is used for creating web sites. In this case Controllers usually return a View (i.e. HTML response) to browser requests. Web APIs on the other hand are usually made to be consumed by other applications. If you want to allow other applications to access your data / functionality, you can create a Web API to facilitate this access. For example, Facebook has an API in order to allow App developers to access information about users using the App. Web APIs don't have to be for public consumption. You can also create an API to support your own applications. For example, we created a Web API to support the AJAX functionality of our MVC web site.
Microsoft changed the way they present the different templates. Now instead of using different templates for different project types, they encourage developers to mix ASP.NET technologies inside the same project as needed. Microsoft calls this vNext.
UPDATE: For ASP.NET Core, Web API has been integrated into the MVC 6 project type and the ApiController class is consolidated into the Controller class. Further details at: https://wildermuth.com/2016/05/10/Writing-API-Controllers-in-ASP-NET-MVC-6
My two cents...
In ASP.Net MVC – the MVC’s Controller decides what should be the View - i.e., the controller decides what the user should “see” (based on the current scenario or context), when they make a request.
In ASP.Net Web Forms, the ASPX pages decides what the user should “see” when they make a request.
But in Web API, there is no control/power to any of the Web API’s features to decide what the user should “see” when they make a request.
Web API is NOT a technology tied up with websites only. It can be used for multiple purposes – not only websites. So it doesn't know the meaning of rendering
Further Reading
Planning Web Solutions Today: Web Forms, ASP.NET MVC, Web API, and OWIN.
WCF or ASP.NET Web APIs? My two cents on the subject
The Next Generation of .NET – ASP.NET vNext
Getting Started with ASP.NET MVC 6
MVC controller derived from controller class. In Mvc you can returns views. Mvc achitecture uses to create an application. However Web apis are used to provide data to various application.
Web Api drives from Api controller and it doesn't return view.
Note: You can also create Web Api from MVC controller but you need to return result as JsonResult or other web api supported return types.
In addition to answers already provided here, its worth noting any controller which inherits from ApiController and having an action with Http verb POST can only have one [FromBody] input parameter. If using a MVC controller (deriving from 'Controller') you can have many post input parameters.
I´m a newbie in ASP .NET MVC technology .
Actually my question is:
Is a PostRepository, used in ASP .NET MVC web app (like this) working as WebService? Or basicaly, when I have ActionResult method in Controller i.e. for deleting some post from db based on PostId as paramether of this method (/post/delete/5 for example) is this web service? Or it´s just a mechanism that MVC use for performing CRUD operations so it´s not a webservice?
It´s true, that ActionResults methods of controller returnig Views are not web services?
The repository pattern is helping you to keep a clear code structure. It explains you how and where to keep the database access functions.
This way you don't overcrowd your code in the controller. Plus you can recycle the code, calling the same function from two different places.
For creating rest web services you should use Web API. And the result of an web service is not an view; it is usually an object.
Returning a View means that you want to display a page and not a service.