title: Why should I use OWIN for a service-based API when I can create web-based RESTful endpoints?
body: <p>I am in the process of rewriting the architecture for an existing application that will be hosted on Azure and have at least two API's - one public, and the other private for internal RESTful-related CRUD calls. </p>
  
  <p>The main technology stack is ODATA, WebAPI2, C#, MVC5, EF, AngularJS.  My thoughts were that the RESTful endpoints would all be exposed through the Azure Web Role (just like any other URL).  </p>
  
  <p>In reading more about <a href="http://www.asp.net/web-api/overview/hosting-aspnet-web-api/host-aspnet-web-api-in-an-azure-worker-role" rel="nofollow">OWIN and using it with the WebAPI and the Azure Worker Role</a>, it seems like exactly the same thing, but as a service.</p>
  
  <p>Is there any advantage to going this OWIN route (where come to think of it, I could even write a WCF service to do the same thing) rather than the web-based RESTful API calls?</p>
  
  <p>I'm looking for some reasons why I should go through the exercise of moving to a service-based API.</p>