Since writing yesterday’s post about what annoys me regarding the limited insight most web developers have in regards to Routing vs Rewriting.  It occurred to me that I might be able to make the difference and benefits between the two more clear, after remembering a post Phil Haack wrote about Editable MVC Routes.

By taking my companies already production ready URL Rewriter that supports runtime-editing of rewriter rules and adding support for routes.  I would essentially be merging together Routing and Rewriting in the same configuration, and making the routes just as editable as the rewriter rules.  By doing this, my hope is that it should illustrate the benefits of having both a Rewriter as well as a Router in your web arsenal, because you can play with both in real time and start to connect in your mind when one is more useful than the other.

I started with the latest release of my companies URL Rewriter and created a contrib project on GitHub that extended the Apache support to also include System.Web.Routing configuration.  The syntax looks similar to the Apache mod_rewrite but specific for routes.  Here is an example of what the config, with both routes and rewriting rules in it, might look like:

RewriteEngine On

#
# Start Rewrite
#

# force to HTTPS
RewriteCond %{HTTPS} (off) [NC]
RewriteRule ^(.*)$ https://www.somesite.com$1 [QSA,L]

# force non-www
RewriteCond %{HTTP_HOST} !^somesite.com$ [NC]
RewriteRule ^(.*)$ http://somesite.com$1 [R=301,L]

# add a trailing slash
RewriteRule ^([^.?]+[^.?/])$ $1/ [R=301,L]

#
# Start Routes
#

RouteDefault controller Home
RouteDefault action Index
RouteUrl {controller}/{action}/{id} "Default"

Notice the standard Route that comes default with an ASP.NET MVC project at the bottom of the traditional rewriter config.  As a planned side-effect of using the Managed Fusion URL Rewriter the routes are completely editable, so they can be changed with out a recompile and with out a restart of the application pool.  So I see those as two huge benefits of using a method like this, on top of illuminating the differences and advantages of using both System.Web.Routing and a URL Rewriter in your application.

The code that I have provided via GitHub provides the following commands that you can use to control your routes:

• RouteUrl <url>  “<name>”
• RouteDefault <url-part>  <default>
• RouteConstraint <url-part>  <regex-constraint>
• RouteNamespace <namespace>
• RouteIgnoreUrl <url>

So I encourage you to check this code out and provide feedback, as I aim to continue to grow this code base where I can to make it easier to have your rewriter and your routes in the same place. Because even though I created it for demonstration reasons, I realize that it may have more of a use for others out there that need to support runtime-editable routes in their application.

Note to readers that have just read my last post: You maybe wondering why I compared routes to unchangeable roads in my last post, and then in this one give people the ability to edit them in real time.  Well I did state in the beginning of this post that the main goal of this project above was to illustrate the differences in real-time of routing and rewriting with out the need to recompile.  Also Phil did concede there are times when routes would be better as dynamic code that can be changed without a recompile:

Having said that, there are many situations in which the ability to change an application’s routes without having to recompile the application comes in very handy. This is the situation I find myself in as I build a blog engine where the folks who will install may want to tweak the routes without having to recompile the blog’s source code.

Update: Here is what you put in your Web.config file to get this working. I have included the whole snippet but the important part is the engineType attribute in the XML below:

<managedFusion.rewriter xmlns="http://managedfusion.com/xsd/managedFusion/rewriter">
    <rules engine="Other" engineType="ManagedFusion.Rewriter.Contrib.RoutingApacheEngine, ManagedFusion.Rewriter.Contrib">
        <apache defaultFileName="rewriter.txt"/>
    </rules>
</managedFusion.rewriter>

As most of you are probably aware, if you read my blog enough, I am the sole developer of a URL Rewriter that I have tried to keep extensible and relevant to the problems that modern web developers face when exposing their applications to the web, by allowing them to have more control over the only interface that matters on the web … THE URL.  The benefits of a URL Rewriter have been explained many times, by many people, so I am not going to add just another rant to the web about keeping your URL’s clean for the search engines.  I will just leave you with Jeff’s explanation of why you shouldn’t ignore the URL.

Having multiple URLs reference the same content is undesirable not only from a sanity check DRY perspective, but also because it lowers your PageRank. PageRank is calculated per-URL. If 50% of your incoming backlinks use one URL, and 50% use a different URL, you aren’t getting the full PageRank benefit of those backlinks. The link juice is watered down and divvied up between the two different URLs instead of being concentrated into one of them.

While Jeff only focuses on the reasons related to SEO, there are many other reasons to make your URL’s “look-and-feel” a high priority.  One that is often touted as a wonderful reason to use a URL Rewriter is to produce pretty looking URL’s, and even though this one of many reasons to use a rewriter, it is really a small part of why you want to have a URL Rewriter in your arsenal as a web developer.  Other reasons include forcing your domain to a constant www vs non-www address, having helper URL’s such as http://www.microsoft.com/sql that redirect to their actual location, and many others.

However, since Microsoft released the System.Web.Routing framework the benefits for using a URL Rewriter have been blurred, because the routing framework gives developers more of an ability to control the URL and thus create prettier URL’s than have traditionally been possible.  Because of this overlap of efforts, in the router and rewriter, in making a more readable URL a misunderstand has been created about the functions and benefits that each provide to the modern web developer.

The first thing to understanding the difference between routes and a rewriter. Phil Haack explains on his blog the reasons routes were not designed to be changeable without a recompile:

This is partly by design as routes are generally considered application code, and should have associated unit tests to verify that the routes are correct. A misconfigured route could seriously tank your application.

In other words the route which is compiled “application code” is like a road, and like the properties of a road it provides a way to get between the starting point and the destination, or in the case of the web the client browser requesting a URL as the start point and your action method as the destination.  If this road could be changed with out much thought, it would be possible to create a circumstance where your destination is no longer accessible by the road. The rewriter on the other hand can be looked at as the rules of the road used to detour traffic, govern the speed, give direction, and really just provide flexibility on top of the rigid start and end points of the road.

When I try to explain this to fellow developers I often have a conversation that goes something like this:

If you have gotten this far in to my rant on the differences of routing and rewriters, you are probably somebody who generally cares and already understands the difference or wants to know more.  If you are that person, I would love to talk to you about what kind of enhancements to my companies URL Rewriter that would make your life easier as a web developer.  As I start to line up the features for the 4.0 release.

I just wanted to share a really well written article on how to setup a Reverse Proxy, by John Gully, using the Url Rewriter that I have been working on for the past 2 years. Here is an excerpt from his article.

I recently came to realize that our website situation was growing out of hand. We had a corporate website, an intranet site, and even a site for web access to email. All of these sites were scattered across multiple servers and each was on a unique port. While this worked, it was not simple. Each new site had to have a new rule configured in the firewall, and who wants the hassle of putting port number at the end of a url?

The solution to this mess turned out to be adding a reverse proxy to our network. By simply providing different urls (www.example.com, mail.example.com) the incomming traffic can be anlayzed by the proxy server and routed to the appropriate internal web server. All the incomming traffic is sent over the default port 80 so the end user never sees any difference. That’s exactly what I wanted, great!

Since our sites are all built upon ASP.NET and hosted on IIS6 the natural option for this was Microsoft ISA Server. Unfortunately, the $1500 cost was way beyond our small company’s internal IT budget. So it was off to Google for me, and after some searching, it appeared that the open source project Url Rewriter by ManagedFusion [sic] seemed to fit the bill.

Thanks for the great write up John.  I hope to be including John’s article in an up coming FAQ wiki on my CodePlex project site in the near future.