Architecture regarding MVC controller vs. separate Web API, how many projects?

Question

In the past, I've always thought about exposing methods that will be consumed on the client side in an separate Web API project. Currently, I'm diving deeper into ASP.NET Core MVC and now understand what controllers are for. (I come from an ASP.Net webforms background)

Given that I might program an app (e.g., with Xamarin) in the future where I would consume most of the same methods from the Core MVC project, it would make sense to separate most of the functionality into a separate api.xxx.com Web API project.

From my point of view, ASP.NET Core MVC controllers are very similar to Web API projects and I fail to see a big difference in terms of consuming them. Basically, I'm confused as to whether have two projects (Core MVC project and separate Web API project) or just a single one.

1. Should I use two projects or just one? What are the advantages and disadvantages? If I use two, based on which criteria do I decide where to add new code? Can I move almost any (what's the exception) code from the controllers in the Core MVC project into the Web API project? Is that a good approach or a bad one?
2. How should I handle the client side login? I know that I can get token-based authentication with OWIN for my Web API project but how should I combine the authentication from the ASP.NET Core MVC project with the Web API project?
3. Let's assume that I decide to just use one project for both. How much overhead is there if the Xamarin app would call the MVC project all the time instead of the Web API project?

Answer 1

There's a lot to unpack in your question. First to your general inquiry:

From my point of view, ASP.NET Core MVC controllers are very similar to Web API projects and I fail to see a big difference in terms of consuming them. Basically, I'm confused as to whether have two projects (Core MVC project and separate Web API project) or just a single one.

That's because there's functionally no difference. In ASP.NET Core, controllers are controllers are controllers. The designations of MVC/Web Api are merely about style. In the former, you'll return views, while in the latter, you're return something like JSON.

Now in truth, the styles have diverged a bit more in later versions of ASP.NET Core. API controllers now usually inherit from ControllerBase rather than Controller and have the [ApiController] attribute applied. However, even this is not a real difference. The attribute just adds some sugar that makes building APIs a bit easier: returning 400 automatically when ModelState is invalid, switching the default bind from FromForm to FromBody, etc. It's all stuff you could do with MVC just as well. Using ControllerBase just excludes stuff included in Controller that's unnecessary for APIs. There's no View method to return because you won't be returning views from an API, for example. Everything else functions the same.

Long and short, it's pretty much about how you implement the controller, not any specific choice of using MVC or Web Api.

Now, as to your specific questions:

1. Should I use two projects or just one? What are the advantages and disadvantages? If I use two, based on which criteria do I decide where to add new code? Can I move almost any (what's the exception) code from the controllers in the Core MVC project into the Web API project? Is that a good approach or a bad one?

Again, a lot here to unpack. Simply, there's no right answer, and frankly, you don't have to decide right now. You can start with just one project mixing and matching MVC and Web Api controllers. Then, if you find a specific need, you can always create a new project and move your Web Api controllers over there. It just depends on your requirements and the needs of your application(s), which unfortunately no one can speak to but you. My best advice always, though, is to start small. Get out of the weeds and just build something. You aren't carving in stone; anything can be refactored later.

2. How should I handle the client side login? I know that I can get token-based authentication with OWIN for my Web API project but how should I combine the authentication from the ASP.NET Core MVC project with the Web API project?

Once you start talking about authenticating multiple apps, you really need to start looking at a centralized identity solution. There's out of the box, low config solutions like Azure AD or Auth0, or you can roll your own with Identity Server. It basically boils down to what you're willing to pay and how involved you want to be.

3. Let's assume that I decide to just use one project for both. How much overhead is there if the Xamarin app would call the MVC project all the time instead of the Web API project?

I don't think you're looking at this the right way. Requests are requests and the question is merely one of scale. The difference between one app (one project) and multiple is simply whether all the requests go to one place or many. However, you can always both vertically (resources) and horizontally (more instances) scale even just one app. So, the performance isn't honestly a concern here. In either form, you're scaling, just in different ways.