Where Marketing, Analytics, and UX meet

RESTful API with dynamically loaded routes

API

Maintenance and growth of a Web API requires a lot of planning.  In the ASP.NET world, you are traditionally looking at recompiling Web applications when you make changes to those compiled services. Well, not anymore. This post is a "how-to" for putting your API route groups (MVC classes that contain the routes for your Web application) into separate projects and then dynamically loading those separately compiled assemblies to find and manage the routes dynamically.

You may have made use of the ASP.NET WebAPI (version 2) before, and the most robust project template gives you examples for how to create all sorts of MVC-style presentations and functions. But your project is then chock-full of code you might never use and all of the code examples put the M-V-C components into the same project as the core site's project.

As you may know, I started off my career in ASP and VB and .NET (later with C#) but then I converted over to PHP and have been working with a lot of open-source for years. So I haven't personally written a lot of .NET in a while. But my team has been needing to refactor our APIs, with the ability to add new branches or route groups for handling new information services via our API, as well as the ability to  fix older APIs and version existing APIs.

One approach we considered was setting up a number of API projects and then using virtual directory structures to create the hierarchy and extensibility we needed. In the end, we decided a that a lot of the general plumbing would be redundant. Imagine owning a big 'ole city buss. The virtual directory approach would be like buying a fleet of city busses to add more seats to match our capacity needs. This would be a common approach in city busses, but what if they were all going to and from the same basic location? At that point you might say, "Hey, we should get out of the city buss business, and get a railroad train instead. Then we can stick with one engine and simply buy more train cars to add seats!" That is the approach we wanted to take.

So I dove back into ASP.NET to re-learn how the WebAPI works and crafted a solution that had one engine (the core API endpoint, site, if you will) and figured out a way to have that "site" dynamically find and load the route group assemblies that were dropped into a folder. When the core Web application starts, figures out where the core app sits on the Web Server and then attempts to search in a specific subfolder for any routes it should add to the API. Adding to and removing compiled assembly DLLs from that subfolder adds to or removes API end point routes from the API as a whole. Each assembly represents a new branch of the API tree, controlled by both the namespace as well as the route prefix.

I had to learn a number of tricks to figure this out and that also included pilfering a bit of stack-overflow answers to figure some stuff out, but now it all seems to be working. The Git repository is free to download and contains a few easy to complex examples for how to author your routes.

https://github.com/enginpost/asp.net-WebApi-Remote-Controllers 

Enjoy! 

Add new comment

*

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
By submitting this form, you accept the Mollom privacy policy.