In this blog, I discuss these limitations and present a possible solution.
Background
The WebApi and Areas features play an important role in the project I am currently working on. In this project, a web application is developed for multiple types of end-users. Areas are used to create separate frontends for each type of end-user. WebApi is used as part of an interaction framework (knockoutjs) that enriches the user experience. Below is a list of relevant design decisions that were made:
- The main MVC application resides in the root of the solution.
- All administrator functionality resides in a separate area.
- Each external party has its own area.
- Each area, including the root, constitutes a well separated functional block. Functionality from one area may not be exposed to another area. This is to prevent unauthorized access of data.
- Each area, including the root, has its own RESTfull API (WebApi).
During the development of this web application, I encountered an important limitation of WebApi when used in conjunction with Areas.
Routing and WebApi
Both regular and WebApi calls use ASP.NET MVC’s routing mechanism to translate HTTP requests to the appropriate controller action. However, only regular calls support areas, while WebApi calls are “arealess”. As a result, WebApi controllers in different areas are actually accessible from all areas. Additionally, having multiple WebApi controllers with identical names in different areas will produce an exception:
Multiple types were found that match the controller named ‘clients’. This can happen if the route that services this request (‘api/{controller}/{id}’) found multiple controllers defined with the same name but differing namespaces, which is not supported.
The request for ‘clients’ has found the following matching controllers:
MvcApplication.Areas.Administration.Controllers.Api.ClientsController
MvcApplication.Controllers.Api.ClientsController
The error message pretty much sums up the problem: ASP.NET MVC 4 RC does not support the partitioning of WebApi controllers across areas.
IHttpControllerSelector
The culprit is the DefaultHttpControllerSelector which is ASP.NET MVC’s default implementation of the IHttpControllerSelector interface. This class is responsible for selecting the appropriate IHttpController (the interface implemented by ApiController), when provided with a HTTP request message. At the heart of the DefaultHttpControllerSelector lies the HttpControllerTypeCache. This class runs through all assemblies that are used by the application and caches all types that implement the IHttpController. The SelectController method of the DefaultHttpControllerSelector uses this cache to lookup a matching type for the given controller name. This operation can end in three different manners:
- No matching types were found, which results in an HttpStatus.NotFound (404).
- One matching type was found, which is returned by the method and ASP.NET MVC continues to process the request.
- Multiple matches were found, which results in an exception similar to one displayed earlier.
In search for a solution
Fortunately, through the power of Inversion of Control, developers can inject their own implementation of IHttpControllerSelector. In a related blog by Andrew Malkov, he attempts to tackle the problem by creating a custom implementation called AreaHttpControllerSelector.
This class allows area specific WebApi controllers to co-exist, provided one makes a minor modification to the WebApi routes. In order to function, a default route parameter called “area” must be added to the HttpRoute definition in the AreaRegistration file.
1 context.Routes.MapHttpRoute(
2 name: "Administration_DefaultApi",
3 routeTemplate: "Administration/api/{controller}/{id}",
4 defaults: new { area = "Administration", id = RouteParameter.Optional }
5 );
Unfortunately, adding this extra parameter introduces a new limitation: Querystring parameters on WebApi calls no longer function. E.g. GET /Administration/api/clients will work, but GET /Administration/api/clients?firstname=john will result in a 404.
Part of the problem lies in the manner in which AreaRegistration is used to define routes. Consider the AdministrationAreaRegistration below:
1 public class AdministrationAreaRegistration : AreaRegistration
2 {
3 public override string AreaName
4 {
5 get
6 {
7 return "Administration";
8 }
9 }
10
11 public override void RegisterArea(AreaRegistrationContext context)
12 {
13 context.Routes.MapHttpRoute(
14 name: "Administration_DefaultApi",
15 routeTemplate: "Administration/api/{controller}/{id}",
16 defaults: new { id = RouteParameter.Optional }
17 );
18
19 context.MapRoute(
20 "Administration_default",
21 "Administration/{controller}/{action}/{id}",
22 new { action = "Index", id = UrlParameter.Optional }
23 );
24 }
25 }
The first route defines how ApiContollers can be reached, while the second route defines how regular controllers can be reached. Both registrations use a different method for registering the route in order to differentiate between normal calls and WebApi calls. Routes registered through MapHttpRoute are meant for WebApi controllers while routes registered through MapRoute are meant for regular controllers.
Note that MapHttpRoute is called on the Routes collection, whereas MapRoute is called on the AreaRegistrationContext itself. This implies that there is a difference between the default MapRoute and the one provided by the AreaRegistrationContext.
After digging through the sourcecode of ASP.NET MVC, I found that the most notable difference is that the MapRoute of AreaRegistrationContext incorporates the AreaName into the route’s metadata. Specifically, the value of the AreaName property is added to the route’s DataTokens.
Solution – Part 1
I created a MapHttpRoute extension method for the AreaRegistrationContext that performed a similar operation as the AreaRegistrationContext.MapRoute method.
1 public static class AreaRegistrationContextExtensions
2 {
3 public static Route MapHttpRoute(this AreaRegistrationContext context, string name, string routeTemplate)
4 {
5 return context.MapHttpRoute(name, routeTemplate, null, null);
6 }
7
8 public static Route MapHttpRoute(this AreaRegistrationContext context, string name, string routeTemplate, object defaults)
9 {
10 return context.MapHttpRoute(name, routeTemplate, defaults, null);
11 }
12
13 public static Route MapHttpRoute(this AreaRegistrationContext context, string name, string routeTemplate, object defaults, object constraints)
14 {
15 var route = context.Routes.MapHttpRoute(name, routeTemplate, defaults, constraints);
16 if (route.DataTokens == null)
17 {
18 route.DataTokens = new RouteValueDictionary();
19 }
20 route.DataTokens.Add("area", context.AreaName);
21 return route;
22 }
23 }
To use the new extension method, remove the Routes property from the call chain:
1 context.MapHttpRoute(
2 name: "Administration_DefaultApi",
3 routeTemplate: "Administration/api/{controller}/{id}",
4 defaults: new { id = RouteParameter.Optional }
5 );
Now both the regular routes and the WebApi routes have knowledge of their corresponding area.
Solution – Part 2
The second part of the solution is to create an implementation of IHttpControllerSelector that actually uses the area name. I took the AreaHttpControllerSelector class from Andrew Malkov’s blog post and used it as a base for my own solution.
1 namespace MvcApplication.Infrastructure.Dispatcher
2 {
3 using System;
4 using System.Collections.Concurrent;
5 using System.Collections.Generic;
6 using System.Globalization;
7 using System.Linq;
8 using System.Net.Http;
9 using System.Web.Http;
10 using System.Web.Http.Controllers;
11 using System.Web.Http.Dispatcher;
12
13 public class AreaHttpControllerSelector : DefaultHttpControllerSelector
14 {
15 private const string AreaRouteVariableName = "area";
16
17 private readonly HttpConfiguration _configuration;
18 private readonly Lazy<ConcurrentDictionary<string, Type>> _apiControllerTypes;
19
20 public AreaHttpControllerSelector(HttpConfiguration configuration)
21 : base(configuration)
22 {
23 _configuration = configuration;
24 _apiControllerTypes = new Lazy<ConcurrentDictionary<string,
Type>>(GetControllerTypes);
25 }
26
27 public override HttpControllerDescriptor SelectController(HttpRequestMessage request)
28 {
29 return this.GetApiController(request);
30 }
31
32 private static string GetAreaName(HttpRequestMessage request)
33 {
34 var data = request.GetRouteData();
35 if (data.Route.DataTokens == null)
36 {
37 return null;
38 }
39 else
40 {
41 object areaName;
42 return data.Route.DataTokens.TryGetValue(AreaRouteVariableName, out areaName) ? areaName.ToString() : null;
43 }
44 }
45
46 private static ConcurrentDictionary<string, Type> GetControllerTypes()
47 {
48 var assemblies = AppDomain.CurrentDomain.GetAssemblies();
49
50 var types = assemblies
51 .SelectMany(a => a
52 .GetTypes().Where(t =>
53 !t.IsAbstract &&
54 t.Name.EndsWith(ControllerSuffix, StringComparison.OrdinalIgnoreCase) &&
55 typeof(IHttpController).IsAssignableFrom(t)))
56 .ToDictionary(t => t.FullName, t => t);
57
58 return new ConcurrentDictionary<string, Type>(types);
59 }
60
61 private HttpControllerDescriptor GetApiController(HttpRequestMessage request)
62 {
63 var areaName = GetAreaName(request);
64 var controllerName = GetControllerName(request);
65 var type = GetControllerType(areaName, controllerName);
66
67 return new HttpControllerDescriptor(_configuration, controllerName, type);
68 }
69
70 private Type GetControllerType(string areaName, string controllerName)
71 {
72 var query = _apiControllerTypes.Value.AsEnumerable();
73
74 if (string.IsNullOrEmpty(areaName))
75 {
76 query = query.WithoutAreaName();
77 }
78 else
79 {
80 query = query.ByAreaName(areaName);
81 }
82
83 return query
84 .ByControllerName(controllerName)
85 .Select(x => x.Value)
86 .Single();
87 }
88 }
89
90 public static class ControllerTypeSpecifications
91 {
92 public static IEnumerable<KeyValuePair<string, Type>> ByAreaName(this IEnumerable<KeyValuePair<string, Type>> query, string areaName)
93 {
94 var areaNameToFind = string.Format(CultureInfo.InvariantCulture, ".{0}.", areaName);
95
96 return query.Where(x => x.Key.IndexOf(areaNameToFind, StringComparison.OrdinalIgnoreCase) != -1);
97 }
98
99 public static IEnumerable<KeyValuePair<string, Type>> WithoutAreaName(this IEnumerable<KeyValuePair<string, Type>> query)
100 {
101 return query.Where(x => x.Key.IndexOf(".areas.", StringComparison.OrdinalIgnoreCase) == -1);
102 }
103
104 public static IEnumerable<KeyValuePair<string, Type>> ByControllerName(this IEnumerable<KeyValuePair<string, Type>> query, string controllerName)
105 {
106 var controllerNameToFind = string.Format(CultureInfo.InvariantCulture, ".{0}{1}", controllerName, AreaHttpControllerSelector.ControllerSuffix);
107
108 return query.Where(x => x.Key.EndsWith(controllerNameToFind, StringComparison.OrdinalIgnoreCase));
109 }
110 }
111 }
If you want to learn more about the technical details of the solution, I suggest you read Andrew’s excellent blog post first. The most significant modifications are:
Changed the GetAreaName method in order to retrieve the area name from the DataTokens property rather than the RouteData.
Added support for “arealess” WebApi controllers (e.g. those that reside in the root) to the GetControllerType method.
Removed the fallback mechanism from the SelectController method. The original implementation would call the SelectController method of the base-class in case GetControllerType failed to produce a result. I preferred an approach where the responsibility of successful controller selection resided in AreaHttpControllerSelector.
Finally, to inject the new AreaHttpControllerSelector class, the following line must be added to the Application_Start method in the Global.asax.cs
1 GlobalConfiguration.Configuration.Services.Replace(typeof(IHttpControllerSelector), new AreaHttpControllerSelector(GlobalConfiguration.Configuration));
After these modifications everything worked as expected!