Programming Microsoft ASP.NET 4 - Dino Esposito [84]
Originally devised for ASP.NET MVC, URL routing gives you total freedom to organize the layout of the URL recognized by your application. In a way, the URL becomes a command for the Web application; the application is the only entity put in charge of parsing and validating the syntax of the command. The URL engine is the system-provided component that validates the URL. The URL routing engine is general enough to be usable in both ASP.NET MVC and ASP.NET Web Forms; in fact, it was taken out of the ASP.NET MVC framework and incorporated in the general ASP.NET system.web assembly a while ago.
URL routing differs in ASP.NET MVC and ASP.NET Web Forms only with regard to how you express the final destination of the request. You use a controller-action pair in ASP.NET MVC; you use an ASPX path in ASP.NET Web Forms.
Original URL Rewriting API
URL rewriting helps you in two ways. It makes it possible for you to use a generic front-end page such as news.aspx and then redirect to a specific page whose actual URL is read from a database or any other container. In addition, it also enables you to request user-friendly URLs to be programmatically mapped to less intuitive, but easier to manage, URLs.
Here’s a quick example of how you can rewrite the requested URL as another one:
protected void Application_BeginRequest(object sender, EventArgs e)
{
// Get the current request context
var context = HttpContext.Current;
// Get the URL to the handler that will physically handle the request
var newURL = ParseOriginalUrl(context);
// Overwrite the target URL of the current request
context.RewritePath(newURL);
}
The RewritePath method of HttpContext lets you change the URL of the current request on the fly, thus performing a sort of internal redirect. As a result, the user is provided the content generated for the URL you set through RewritePath. At the same time, the URL shown in the address bar remains as the originally requested one.
In a nutshell, URL rewriting exists to let you decouple the URL from the physical Web form that serves the requests.
Note
The change of the final URL takes place on the server and, more importantly, within the context of the same call. RewritePath should be used carefully and mainly from within the global.asax file. In Web Forms, for example, if you use RewritePath in the context of a postback event, you can experience some view-state problems.
One drawback of the URL rewriting API is that as the API changes the target URL of the request, any postbacks are directed to the rewritten URL. For example, if you rewrite news.aspx?id=1234 to 1234.aspx, any postbacks from 1234.aspx are targeted to the same 1234.aspx instead of to the original URL.
This might or might not be a problem for you and, for sure, it doesn’t break any page behavior. However, the original URL has just been fully replaced while you likely want to use the same, original URL as the front end. If this is the case (and most of the time, this is exactly the case), URL rewriting just created a new problem.
In addition, the URL rewriting logic is intrinsically monodirectional because it doesn’t offer any built-in mechanism to go from the original URL to the rewritten URL and then back.
URL Patterns and Routes
The URL routing module is a system component that intercepts any request and attempts to match the URL to a predefined pattern. All requested URLs that match a given pattern are processed in a distinct way; typically, they are rewritten to other URLs.
The URL patterns that you define are known as routes.
A route contains placeholders that can be filled up with values extracted from the URL. Often referred to as a route parameter, a placeholder is a name enclosed in curly brackets { }. You can have multiple placeholders in a route as long as they are separated by a constant or delimiter. The forward slash (/) character acts as a delimiter between