ASP.NET Web API 2 hosting differences [closed]

Question

I have found out that Web API 2 can be hosted with 2 techniques:

• A) IIS - web application
• B) OWIN - console application

But what I couldn't find is the difference between them. Why should I use one over the other? Are there any advantages or disadvantages?

Answer 1

Note that IIS and OWIN are not mutually exclusive. You can host an OWIN application in IIS: https://docs.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/getting-started-with-owin-and-katana#host-owin-in-iis

So from here let's assume you are asking about the distinction between IIS hosted apps versus self hosted OWIN apps(since you mentioned console app).

IIS

• IIS is more full featured and mature. There's a wide range of features already built into IIS.
• IIS has a wide range of integrations such as management interfaces.
• IIS is well known by experienced devs and administrators, and thus leveraging IIS means that you can be sure IIS features you use are documented and understood by experienced staff.
• IIS can easily host multiple sites behind a single port on a domain, such as port 80. When you host multiple web apps, they are all accessible on port 80, and IIS can route requests to the appropriate app based on domain or URL.

OWIN

• OWIN self hosting by default cannot host multiple sites on a single port. Each process is assigned a port. Generally a self hosted web app is its own process(such as a console app), and thus is a assigned a port. You could leverage IIS or another web host application to reverse proxy requests through port 80 to your multitude of self hosted apps, routing them based on something such as URL. Or you could write you own port router.
• As above, you can't have a self hosted app on the same server as IIS and both respond to port 80. One will need to be at a different port. Again IIS could have 80 and reverse proxy to whatever port the self hosted OWIN app is at.
• OWIN gives you more control over the request/response pipeline. Alot of things were possible in ASP.NET through request Handlers and Modules, but there were some limitations or baked in behaviors that were hard to override in certain situations. OWIN opens up the processing pipeline to give you more control.
• There will be some things you want to accomplish for which you can find handlers and modules easily, but there may not yet be equivilant OWIN middleware implementations yet. Many common tasks are readily available, and many well maintained open source libraries already have support for OWIN. So this applies mainly to edge case things that are less common.
• Self-hosting frees you from requiring IIS on a machine. Given you follow certain guidelines, you could deploy a properly built OWIN application to Linux and reverse proxy requests through a Linux web host such as Apache. The OWIN app could be self hosted with Kestrel.

Obviously not a complete list.

I think going forward it's probably advisable to use OWIN in IIS. This is because OWIN is quickly becoming the standard. I think for most people who understand it, if given the choice they would choose OWIN everytime for new projects, given there is no conflict with legacy projects. And since IIS is a very mature, secure, full featured, and stable web hosting application, then we choose to host our OWIN web app in IIS. This also means the web app will be tested and compatible with IIS based cloud services such as Azure App Service.