Can I have many distinct APIs in one project?

[ahofman]

Is there any way that I can have many different APIs in a single project?

Say I have a set of controllers in one namespace ("api1"), and another set of controllers in a different namespace ("api2"). Each set of controllers will have different authentication, authorization, etc.
I want two separate swagger documents, one for each API, so I believe I also want separate ApplicationObjects.

Is this possible - am I heading down the wrong road? What are the alternatives?

Thankyou for your assistance :)

[rynowak]

I think the first question to ask is, do you plan on deploying two sites or one site?

If the answer is two sites then this is pretty easy. You can remove the unwanted controllers using an application model convention at startup time.

If the answer is one site then you'll hit a point where you need two different service providers. We've done some experimenting with this but don't have a published solution yet. The idea with this is to have a 'dispatcher' app that receives requests, and then forwards them to a 'tenant' app which processes. Because each tenant has it's own services, it's totally isolated. The fact that the controllers happen to be in the same assembly is just a details.

That aside, you should take a look at Orchard, which has already solved a lot of problems in this space around multitenancy if that's what you need. I'm not familiar with the kinds of things they do with APIs but @sebastienros should be able to help you.

[PonchoPowers]

For anyone else reading this see: https://www.strathweb.com/2017/04/running-multiple-independent-asp-net-core-pipelines-side-by-side-in-the-same-application/

[tugberkugurlu]

For anyone else reading this see: https://www.strathweb.com/2017/04/running-multiple-independent-asp-net-core-pipelines-side-by-side-in-the-same-application/

This is good but has a lot of problems I think for it to be used in anger. TBH, Filip seems to have done as much as he could to make this work but the framework doesn't allow this isolation to happen w/o much issues. Based on this example (keep in mind that this doesn't do the action selection separately but it's still enough to highlight the issues):

• you can still request HTTP GET /limits from the server in addition to HTTP GET /internal/limits. That's sad. Not sure why this happens. I was hoping that branch would have scoped things nicely but apparently not.
• you cannot share dependencies from Startup.ConfigureServices even if you want to. Each pipeline is "really" totally isolated. That's good but not good for cases where you want to scope it globally. In my case, I wanted to have this only globally.
• any dependency being passed from the hosting layer (through WebHost.CreateDefaultBuilder(args).ConfigureServices method) is now ignored inside each branch.