Any feedback much appreciated.
I need to create a Web API (ASP.NET Core Web API), which does some basic CRUD operations. Thats no issue at all, and I need to create a simple Angular UI for the Web API as well. Thats also no issue. But is there a way to combine both into a single application ? WebAPI mainly and an optional UI part in Angular than having a second angular solution ? I know there is a visual studio project template where you create a .NET Core Angular Application, if I do that, how would I expose the API at the sametime to other clients as API, while still managing the Angular UI ?
Put in another way, my .NET Core application should be primarily a WebAPI which should work independently and act like a WebAPI, while an optional part of it should have an Angular frontend connecting to the WebAPI.
You can view this as a matter of security for your WebAPI and how you expose connections to it. You can serve your API endpoints under one route, i.e. /api and you Angular application at you site route or host it elsewhere.
If you follow the same practices for exposing the WebAPI cross origin, then your Angular application can consume the API in exactly the same way as any other client would.
Followed #johnny's comment and it works !
All you have to do is compile your angular project and put it under wwwroot. Then you can navigate to your index.html page, set your webapi startup to serve static files and your done
Related
I'm mostly back end developer and want to start small side project.
I want to do razor pages web app and as a part of it I would like to have web api that can be consumed outside of the app and if I want, use it to build other front end with it.
What would be good project structure? I don't want to have it deployed as 2 apps. One for razor, second for web API. I would like to have it as a one deployed app.
Is this good approach?
Thanks
I tried separate razor pages app and separate web api. Deployed as two pages.
Since you're building a Web API project anyway, you should consider making a frontend application with a framework like Vue that interacts with the API, instead of a Razor project. Having both a Razor project and a Web API project would be redundant as both of them would have to incorporate most of the same backend code.
It better separates the role of the frontend and backend applications, and Microsoft's documentation suggests using this project structure too.
You'd have to deploy two separate apps, but this would be a more suitable approach.
If you still want to deploy one application only, you could just incorporate Web API services in your Razor app, but this really isn't recommended.
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.
We have a Spa client, which runs inside of a aspnet core web app (aspnet core spa template). The Api project is where the business logic and data access reside and can be called by other clients such as native, other Spas, etc… The web app is protected by a cookie middlewre with external providers to sign-in, while the web api is protected by bearer tokens.
We have noticed that if we add a reference in the Web app to the Api project, the Controllers defined in the Api project are available in the web app. So just by adding a reference, we can make a local ajax call to /api/data from Spa residing in the Web app. There is nothing extra we’re doing here, no custom controller resolvers, assembly loading, etc…
Is that how things now work in aspnet core mvc? Are we correct to assume that the web app will just discover the controllers, but ignore any program.cs/startup.cs from the Api project when it configures the host?
No. This is not how it works. First, the delineation between "MVC" and "Web Api" is more pedantic than anything at this point. In Core, they are the same. If your project is only going to be an API, you can leave a few things out of the standard MVC services, but it still use "MVC". As a result, calling something an "API" or "MVC" project doesn't really mean anything. You can mix and match to whatever degree you need.
If you have two separate projects, then you should follow that and keep everything separate. One should not have a dependency on the other. You can always "call" your API from your MVC project, just as with any other HTTP-hosted service. However, you won't be able to take advantage of things like UrlHelper to generate URLs for your API action from your MVC project. You would just need to "know" these.
If you want the two projects to be tightly integrated, then they shouldn't be two projects. Just have one website project, and move all your API and MVC stuff into it. Then, you'll truly have everything shared.
If i want to use WebAPI as a service to connect to multiple databases on different servers and retrieve the data that my MVC application will use what is the best way to do it?
I don't want do have ApiController(s) in the same project as my MVC project so do i need to add a new WebApi project (delete all except controllers and stuff that the template adds to have a clean project) that my MVC application will reference?
Here's the list of tutorials/blog posts i used to learn about WebAPI:
ASP.NET Web API - Screencast series with downloadable sample code
http://weblogs.asp.net/jgalloway/archive/2012/03/16/asp-net-web-api-screencast-series-with-downloadable-sample-code-part-1.aspx
Consuming ASP.NET Web API Service using HttpClient
http://debugmode.net/2012/03/03/creating-first-http-service-using-asp-net-web-api-part1-of-many/
http://debugmode.net/2012/03/07/consuming-asp-net-web-api-service-using-httpclient-part2-of-many/
CRUD operation using ASP.NET Web API and MVC4
http://www.dotnetglobe.com/2012/03/crud-operation-using-aspnet-web-api-in.html
http://www.dotnetglobe.com/2012/03/crud-operation-using-aspnet-web-api-in_28.html
Creating a .Net queryable client for ASP.Net Web API oData services
http://blog.petegoo.com/index.php/2012/03/11/creating-a-net-queryable-client-for-asp-net-web-api-odata-services/
Using HttpClient to Consume ASP.NET Web API REST Services
http://www.johnnycode.com/blog/2012/02/23/consuming-your-own-asp-net-web-api-rest-service/
Client side support with the ASP.NET Web API
https://msmvps.com/blogs/theproblemsolver/archive/2012/03/13/client-side-support-with-the-asp-net-web-api.aspx
Create and Consume ASP.Net Web API REST Services - MVC4
http://www.askamoeba.com/Opensource/Opensourcedetail/144/Create-and-Consume-ASP-Net-Web-API-REST-Services-MVC4
Building and consuming REST services with ASP.NET Web API using MediaTypeFormatter and OData support
http://robbincremers.me/2012/02/16/building-and-consuming-rest-services-with-asp-net-web-api-and-odata-support/
Using JSON.NET with ASP.NET Web API
http://blogs.msdn.com/b/henrikn/archive/2012/02/18/using-json-net-with-asp-net-web-api.aspx
Creating Custom CSVMediaTypeFormatter In ASP.NET Web API for Comma-Separated Values (CSV) Format
http://www.tugberkugurlu.com/archive/creating-custom-csvmediatypeformatter-in-asp-net-web-api-for-comma-separated-values-csv-format
Implementing CORS support in ASP.NET Web APIs
http://blogs.msdn.com/b/carlosfigueira/archive/2012/02/20/implementing-cors-support-in-asp-net-web-apis.aspx
How I see Web API
http://thedatafarm.com/blog/asp-net/how-i-see-web-api/
You may use a completely different project to host your Web API controllers. Yet in this case you need to think about the deployment.
Web API is just a web project. It will have its own config file. It will be likely that it will run in its own worker process (depending on how you deploy it).
So if you partition the Web API out, then you get more flexibility but you might end up duplicating a lot of config.
My advice is that, if you do, make sure both projects talk to the same base services projects. Partitioning can also make sense if this Web API might be used by third parties.