I have an ASP.NET MVC Framework (.NET Framework 4.7.2) Web App. Right now it runs on IIS Server and uses the MS SQL database. A huge part of business logic and website itself was written years ago by another company. I hold source codes of the assemblies.
The issue I have is that I have to add web API to the project. The API will contain only a few controller methods, nothing special. I don’t know which approach would be the best in the situation. I’d read tons of posts on SO and so on, but still not convinced.
My first idea was to add the "Microsoft ASP.NET Web API" package and set up the routes to the API in the Global.asax.cs
file before setting up the web page routing. After that, I could add controllers (with the attribute [Route("api/[controller]")]
and add changes in the IoC container. So, I’d have two types of controllers in the solution, one which inherits after the Controller
class and another that inherits after the ApiController
class. But I am also obligated to provide the authorization process in the API. So not sure how to do that in this scenario.
Another idea is to create a separate project in the solution, only for the API project. I’d use assemblies (let’s say, business logic) used in the web page project. And I’d create another IIS Website where I’d put the API. I’d have two websites (Web Page and the API) communicating with MS SQL Server using the same connection strings, not sure does it could work? Both websites would have their copy of assemblies files. Adding the authorization seems much simpler in this case (?).
I think the second one is the cleaner one, but taking into account the fact I need only, let’s say, fifteen controllers method for the API, it might be too much effort. But how to provide the authorization if everything is in one place?
Edit
I’ve decided to use the first approach mentioned before. Because I have only a few controllers, literally a dozen or so, it seems the most straightforward idea. I’ve set up the API routing – before the MVC routing – via setting up the attribute routing and convention-based routing.
config.MapHttpAttributeRoutes();
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional });
Later on, in the different assemblies, I’ve registered the API controllers in the Autofac IoC container next to regular MVC controllers.
builder.RegisterControllers(assembly).PropertiesAutowired(PropertyWiringOptions.AllowCircularDependencies);
builder.RegisterApiControllers(assembly).PropertiesAutowired(PropertyWiringOptions.AllowCircularDependencies);
In the end, I’ve set up the Dependency Resolver.
IContainer container = builder.Build();
DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
GlobalConfiguration.Configuration.DependencyResolver = new AutofacWebApiDependencyResolver(container);
I haven’t yet used authentication and authorization mechanisms, but I intend to do it soon. I am about to use JWT to authenticate and authorize requests as Bruce Zhang suggested. I think that approach should work out next to the cookie authentication I use in MVC.
2
Answers
yes, Running multiple project at same time is possible in Visual Studio
go to solution and set startup project to multiple (choose from your project list)
From my point of view, both ideas you mentioned are feasible. They each have their pros and cons.
First idea
The advantage of the first idea is that API and MVC are integrated in a website, and there is no cross-domain problem. But there is a downside, if the site is a big project, a problem somewhere can affect the whole. You need to troubleshoot the API and MVC separately.
A great choice I can provide is using
Authentication
andAuthorization Filter
.If you have user model in MVC project, this becomes easy. Just set different roles for different users, and then add Filter Attribute on APIController or Action. This will filter out users who do not meet the requirements.You can refer to this docs and this article. Both of them are helpful to me.
Second idea
The advantage of the second idea is that they are easy to troubleshoot and debug. And as you said, it is clean. But the downside is if it need to communicate with MVC site, you need to enable CORS.(set in Web API and IIS)
You don’t need to worry about it. Multiple sites can use same connection string to communicate with SQL. There’s a module called Connection Strings on IIS. It is used to set connection string.