The code for this post can be found in the MSDN Code Gallery.
For a controller type in the ASP.NET Web API to be accessible, it needs to follow some rules:
That’s fairly simple, but there are always people who have a scenario where they need a controller class don’t want to follow all of those rules. This is possible to do and actually fairly simple, by using a controller factory.
The IHttpControllerFactory is the interface responsible for defining how controller classes are found in the solution, and how to map the incoming requests to those controllers. It’s also responsible for creating the actual instance of the controller and for disposing the controller instance once it’s finished processing the request (hint: if you want to implement an instancing mode other than “per call”, that’s the place to go – but that’s a topic for another post). There’s one concrete implementation of the controller factory, appropriately called DefaultHttpControllerFactory, which enforces the rules mentioned above. But that doesn’t prevent us from creating another one which implements a different set of rules (the controller will still need to implement IHttpController, though, that’s not negotiable).
In this example, I’ll show one factory which requires the controller classes to have an “Api” suffix (although still supporting classes ending with “Controller”). Let’s start with the class (the code is in VB this time for a change, but in the code gallery I’ll add a C# version as well). This factory will look for all types in the same assembly as the factory is running (change the logic in the ApiControllerTypes property for a different search place).
The CreateController method is the one which will actually create the controller. This implementation first tries to see if the type is one supported by this class (i.e., ends in “Api”). If it’s not, it just delegates the call to the default factory. If the type is a supported one, we’ll create a new HttpControllerDescriptor, given the controller type. Finally, we’ll use the IHttpControllerActivator from the description to create the actual controller instance – we could use something like Activator.CreateInstance for simple cases, but the activator takes care of IoC parameters as well. The factory then needs to assign the instance to the controller context (I forgot to do that at first, and was getting some exceptions inside the runtime).
Finally, the ReleaseController implementation will just delegate all calls to the default factory (even those controllers handled by this type), since the default factory calls dispose on types which implement IDisposable, and that’s a nice pattern to follow.
And that’s it. On the code gallery sample there are some test controllers and a client application which validates that we can call both controllers with “Controller” and with “Api” suffixes.
[Code in this post]