This project is read-only.

HostedHttpRouteCollection replaces my inherited routes

Topics: ASP.NET Web API, General
Jul 22, 2012 at 9:08 AM
Edited Jul 22, 2012 at 9:47 AM

OK, I am working on a different approach to routing (implementing hierarchical routing) and I have inherited from HttpRoute and overriden a few things.

Now when I add my route to GlobalConfiguration.Configuration.Routes, I was surprised that my behaviour does not get triggered. After some head-scratching, if found this in HostedHttpRouteCollection:


        public override void Add(string name, IHttpRoute route)
            _routeCollection.Add(name, route.ToRoute());


So whatever implementation I have for my route, it is being ignored since HostedHttpRouteCollection turns it into the route it likes!

First of all, a collection is not expected to just suddenly covert the value being added. This is not the way all collections AFAIK work.

On the other hand, This line in .ToRoute() defeats the object oriented inheritance in routing:


            HostedHttpRoute hostedHttpRoute = httpRoute as HostedHttpRoute;
            if (hostedHttpRoute != null)
                return hostedHttpRoute.OriginalRoute;


httpRoute parameter passed in here is of type IHttpRoute. So unless it is a HostedHttpRoute, it will be turned into one and with HostedHttpRoute an internal class, I have no chance of overriding behaviour! Again this to me, defeats the OO approach when I have to check the type of the inherited type.

It looks to me that you guys have done a great job bringing MVC and Web API routing together - which I am sure was not easy at all. This seemed to have resulted in some compromises here and there and with Web API routing needing some new requirements, solutions was to translate traditional routing into Web API routing which causes inherited behaviours being ignored.

Reality is IHttpRoute does not define not just a data bag. It expresses important overridable behaviours. This implementation keeps the data at the time of onversion but throws away the behaviour. So to me solution is to use composition rather than conversion, to add new stuff while keeping the old behaviour. I can work on this and send a Pull Request if you happy.

So it is at all possible to have my alternative routing logic plugged in?



Jul 22, 2012 at 2:18 PM

Take a look at this project  I replaced the standard routing behaviour with a hierarchical router.  I avoid the problem you are having by not using the Routes collection but by using a MessageHandler to trigger the routing.

Jul 22, 2012 at 8:40 PM
Edited Jul 22, 2012 at 11:02 PM

Thanks Darrel. @AlexZeitler notified me of this and I have been reviewing it. But it seems to be built against beta and not RC so cannot quite get it working, but a lot of work has gone into it and the fluent interface is really nice.

My preference - and I believe the ideal approach - is to implement this in routing itself. MessageHandler approach seems to me a bit invasive. I cannot see how you can mix normal routing with API routing something that is a common scenario when a project hosts both MVC and Web API. Also this implementation not only does the routing, but it has knowledge of the controller invocation.

Having said that, I can understand your desire to change the routing altogether since it is flat and a lot of the functionality of routing was designed for MVC.

Jul 23, 2012 at 7:37 PM
As you've discovered, the Web API routing system is not designed to support the notion that you would write a "dual-homed" route; that is, a route the understands both ASP.NET routing AND Web API routing. It only supports the notion of registering Web API routes through its extension method. You can open a feature request for this, but it feels extremely niche to me. I'd rather understand the actual problem you're trying to solve, and see if we can't enable that inside the confines of Web API routes (which would then work for both self-hosting and web-hosting).
Jul 23, 2012 at 11:31 PM

Thanks Brad for the confirmation.

I am fairly active in the Q&A forums in the community (StackOverflow, etc) and I can tell you resource organisation is among the most asked questions - and probably the least answered ones. And part of the problem lies with the flat structure of the routing. I nearly wrote my blog post on how to do hierarchical routing (only to find out that it was not possible to my surprise the way I wanted to do) just to answer these questions.

OK, I will raise a feature request as I believe ASP.NET routing's flexibility needs to be maintained in Web API, and even more so.

Nov 15, 2012 at 10:24 PM

I have checked in a fix this issue. Check out