How feature complete is asp.net web api self-hosting?

Question

I have a requirement that I need to be able to have a stand-alone version of application, as well as an online version. One possible way of doing this would be to have a WPF version, which would satisfy stand-alone, and an MVC Web version.

Obviously, that would require two code bases (though admittedly they should be identical except the front end code). Is Web API self-hosting stable enough that I could just host a full-blown web app inside of it if I needed to?

Answer 1

Web API can run selfhosted but for running ASP.NET (MVC) you require a server like IIS (Express) .

What you can do is have IIS Express installed on a machine, host your Web app in that and have Web API self hosted if needed. Of course if you already have IIS Express installed you might simply want to opt to run everything in it: both Web app and Web API.

Answer 2

Provided you're ok with using both internal/external apps using the same database/service you could host a single version of the WebAPI server in IIS, and simply use it for API Controllers.

You could then use two identical ASP.Net MVC sites (rather than Desktop & Web), which make calls into your WebAPI service. One hosted on the intranet, one on the internet - both hitting your WebAPI for business functionality & data persistance.

The goal here is to reduce the amount of code maintained. Essentially, it's two projects - your WebAPI project, and an ASP.Net MVC site.

Answer 3

I use Web API for self-hosting a number of projects that are in production. The web site http://www.hypermediaapi.com is a self hosted Web API.

Answer 4

No need to have two or more code bases for this scenario. What you need is a library what provides the API for your applications. The library can be used directly in the standalone application what I assume is a desktop app.

You can then create a WCF or Web API or even both layer what isn't anything more than a wrapper around the same library. The WCF/Web API contracts can be the same as your DTOs so the WCF service implementation would be something like this:

SomeObject IMyService.DoStuff(string param)
{
  var myLibrary = new MyLibrary();
  var someObject = myLibrary.DoStuff(param);
  return someObject;
}

The only overhead would be that when an interface changes in library the changes have to be repeated in service interfaces too, but no actual business logic would be duplicated. You can even share the interfaces, ie the API would expose the same interfaces what are implemented by the WCF service if you don't mind having the contract attributes on library interfaces.