Architect an API layer : <p>Broad, general question:</p>

<p>We have an app that is quickly approaching legacy status. It has three clients: Windows app, browser (web site) and mobile.  The data access layer is convoluted at best and has grown organically over the years.</p>

<p>We want to re-architect the whole thing.  The Windows app will go away ('cause who does <em>that</em> any more?)  We will only have the browser based website and the mobile app, both of which will consume the (as of today, non-existant) API layer.  This API layer will also be partially exposed to third parties should they wish to do their own integrations.</p>

<p>Here's my question:</p>

<p>What does this API layer look like?  And by that, I mean... let's start in the Visual Studio solution.  Is the API a separate website?  So on IIS, will there be two sites... one for the public facing website and another for the API layer?</p>

<p>Or, should the API be a .dll within the main website, and have the endpoint URL's be part of the single website in IIS?</p>

<p>Eventually, we will want to update and publish one w/o impacting the other.  I'm just unsure, on a very high level, how to structure the entire thing.</p>

<p>(If it matters:  Each client has their own install, either locally on their network, or cloud hosted.  All db's are single tenant.)</p>
