From quickly reading about AttributeRouting, the biggest difference between it and JuniorRoute is that AttributeRouting apparently sits on top of the ASP.NET MVC framework and Web API--both of those technologies are flawed, in my opinion. JuniorRoute does not; instead, JuniorRoute hooks directly into the ASP.net pipeline and does not reference a single ASP.NET MVC binary.

When I set out building this, I was determined to provide a solution that implemented routing in an HTTP-centric way, not the controller-centric way that ASP.NET MVC does. I think I've managed to accomplish this but I'm only one man and my opinion is, of course, biased. :)

The AttributeRouting project has it right with regards to attributes, but the project's foundation--ASP.NET MVC--is still flawed.

Some developers scoff at the use of attributes because they view attributes as magic. In my experience, attributes are a great way to implement the convention-over-configuration paradigm, but purists may choose to rely on other mechanisms for generating routes. I was sure to design the framework such that both camps--the pragmatists and the purists--could be made happy.

JuniorRoute provides built-in conventions that use endpoint namespaces, class names and method names to generate routes (this is similar to FubuMVC). The great thing is, developers can very easily extend JuniorRoute and create their own convention implementations if the built-in ones are insufficient.

Another way JuniorRoute differs from AttributeRouting is much of JuniorRoute's source code implements the HTTP 1.1 specification directly. For example, JuniorRoute's CacheableResponseHandler class handles prevalidation headers (the If-* headers). Obviously, JuniorRoute is open-source so anyone can look at the class and determine how it does that or implement their own response handler that follows the specification in a different way. ASP.NET MVC tends to hide things like that. I wanted developers to be able to choose from a stock of built-in conventions providing implementations of the most common scenarios but still have the extensibility just in case JuniorRoute doesn't cover something they need.

There are very few classes in JuniorRoute that do not implement interfaces. I designed the framework to be nearly completely extensible while still keeping bootstrapping code and configuration to a minimum. One of my biggest goals is to keep the amount of time between bootstrapping and writing endpoint methods to a minimum. I will be releasing Visual Studio project templates to make initial bootstrapping even simpler; right now, there are a lot of manual steps because one must begin with the ASP.NET Empty Web Application template.