As of version 4.0 ASP.
NET natively supports routing via the now built-in System.Web.Routing namespace. Routing features are automatically integrated into the HtttpRuntime via a few custom interfaces. New Web Forms Routing Support In ASP.
NET 4.0 there are a host of improvements including routing support baked into Web Forms via a RouteData property available on the Page class and RouteCollection.MapPageRoute() route handler that makes it easy
to route
to Web forms.
To map ASP.
NET Page routes is as simple as setting up the routes with MapPageRoute:protected void Application_Start(object sender, EventArgs e)
{
RegisterRoutes(RouteTable.Routes);
}
void RegisterRoutes(RouteCollection routes)
{
routes.MapPageRoute("StockQuote", "StockQuote/{symbol}", "StockQuote.aspx");
routes.MapPageRoute("StockQuotes", "StockQuotes/{symbolList}", "StockQuotes.aspx");
}
and then accessing the route data in the page you can then use the new Page class RouteData property
to retrieve the dynamic route data information:public partial class StockQuote1 : System.Web.UI.Page
{
protected StockQuote Quote = null;
protected void Page_Load(object sender, EventArgs e)
{
string symbol = RouteData.Values["symbol"] as string;
StockServer server = new StockServer();
Quote = server.GetStockQuote(symbol);
// display stock data in Page View
}
}
Simple, quick and doesn’t require much explanation. If you’re using WebForms most of your routing needs should be served just fine by this simple mechanism. Kudos
to the ASP.
NET team for putting this in the box and making it easy!
How Routing Works
To handle Routing in ASP.
NET involves these steps:
Registering Routes
Creating a custom RouteHandler
to retrieve an HttpHandler
Attaching RouteData
to your HttpHandler
Picking up Route Information in your Request code
Registering routes makes ASP.
NET aware of the Routes you want
to handle via the static RouteTable.Routes collection. You basically add routes
to this collection
to let ASP.
NET know which URL patterns it should watch for. You typically hook up routes off a RegisterRoutes method that fires in Application_Start as I did in the example above
to ensure routes are added only once when the application first starts up. When you create a route, you pass in a RouteHandler instance which ASP.
NET caches and reuses as routes are matched.
Once registered ASP.
NET monitors the routes and if a match is found just prior
to the HttpHandler instantiation, ASP.
NET uses the RouteHandler registered for the route and calls GetHandler() on it
to retrieve an HttpHandler instance. The RouteHandler.GetHandler() method is responsible for creating an instance of an HttpHandler that is
to handle the request and – if necessary –
to assign any additional custom data
to the handler.
At minimum you probably want
to pass the RouteData
to the handler so the handler can identify the request based on the route data available.
To do this you typically add a RouteData property
to your handler and then assign the property from the RouteHandlers request context. This is essentially how Page.RouteData comes into being and this approach should work well for any custom handler implementation that requires RouteData.
It’s a shame that ASP.
NET doesn’t have a top level intrinsic object that’s accessible off the HttpContext object
to provide route data more generically, but since RouteData is directly tied
to HttpHandlers and not all handlers support it it might cause some confusion of when it’s actually available. Bottom line is that if you want
to hold on
to RouteData you have
to assign it
to a custom property of the handler or else pass it
to the handler via Context.Items[] object that can be retrieved on an as needed basis.
It’s important
to understand that routing is hooked up via RouteHandlers that are responsible for loading HttpHandler instances. RouteHandlers are invoked for every request that matches a route and through this RouteHandler instance the Handler gains access
to the current RouteData. Because of this logic it’s important
to understand that Routing is really tied
to HttpHandlers and not available prior
to handler instantiation, which is pretty late in the HttpRuntime’s request pipeline. IOW, Routing works with Handlers but not with earlier in the pipeline within Modules.
Specifically ASP.
NET calls RouteHandler.GetHandler() from the PostResolveRequestCache HttpRuntime pipeline event. Here’s the call stack at the beginning of the GetHandler() call:
which fires just before handler resolution.
Non-Page Routing – You need
to build custom RouteHandlers
If you need
to route
to a custom Http Handler or other non-Page (and non-MVC) endpoint in the HttpRuntime, there is no generic mapping support available. You need
to create a custom RouteHandler that can manage creating an instance of an HttpHandler that is fired in response
to a routed request. Depending on what you are doing this process can be simple or fairly involved as your code is responsible based on the route data provided which handler
to instantiate, and more importantly how
to pass the route data on
to the Handler.
Luckily creating a RouteHandler is easy by implementing the IRouteHandler interface which has only a single GetHttpHandler(RequestContext context) method. In this method you can pick up the requestContext.RouteData, instantiate the HttpHandler of choice, and assign the RouteData
to it. Then pass back the handler and you’re done.Here’s a simple example of GetHttpHandler() method that dynamically creates a handler based on a passed in Handler type./// <summary>
/// Retrieves an Http Handler based on the type specified in the constructor
/// </summary>
/// <param name="requestContext"></param>
/// <returns></returns>
IHttpHandler IRouteHandler.GetHttpHandler(RequestContext requestContext)
{
IHttpHandler handler = Activator.CreateInstance(CallbackHandlerType) as IHttpHandler;
// If we're dealing with a Callback Handler
// pass the RouteData for this route
to the Handler
if (handler is CallbackHandler)
((CallbackHandler)handler).RouteData = requestContext.RouteData;
return handler;
}
Note that this code checks for a specific type of handler and if it matches assigns the RouteData
to this handler. This is optional but quite a common scenario if you want
to work with RouteData.
If the handler you need
to instantiate isn’t under your control but you still need
to pass RouteData
to Handler code, an alternative is
to pass the RouteData via the HttpContext.Items collection:IHttpHandler IRouteHandler.GetHttpHandler(RequestContext requestContext)
{
IHttpHandler handler = Activator.CreateInstance(CallbackHandlerType) as IHttpHandler;
requestContext.HttpContext.Items["RouteData"] = requestContext.RouteData;
return handler;
}
The code in the handler implementation can then pick up the RouteData from the context collection as needed:RouteData routeData = HttpContext.Current.Items["RouteData"] as RouteData
This isn’t as clean as having an explicit RouteData property, but it does have the advantage that the route data is visible anywhere in the Handler’s code chain. It’s definitely preferable
to create a custom property on your handler, but the Context work-around works in a pinch when you don’t’ own the handler code and have dynamic code executing as part of the handler execution.
An Example of a Custom RouteHandler: Attribute Based Route Implementation
In this post I’m going
to discuss a custom routine implementation I built for my CallbackHandler class in the West Wind Web & Ajax Toolkit. CallbackHandler can be very easily used for creating AJAX, REST and POX requests following RPC style method mapping. You can pass parameters via URL query string, POST data or raw data structures, and you can retrieve results as JSON, XML or raw string/binary data. It’s a quick and easy way
to build service interfaces with no fuss.
As a quick review here’s how CallbackHandler works:
You create an Http Handler that derives from CallbackHandler
You implement methods that have a [CallbackMethod] Attribute
and that’s it. Here’s an example of an CallbackHandler implementation in an ashx.cs based handler:// RestService.ashx.cs
public class RestService : CallbackHandler
{
[CallbackMethod]
public StockQuote GetStockQuote(string symbol)
{
StockServer server = new StockServer();
return server.GetStockQuote(symbol);
}
[CallbackMethod]
public StockQuote[] GetStockQuotes(string symbolList)
{
StockServer server = new StockServer();
string[] symbols = symbolList.Split(new char[2] { ',',';' },StringSplitOptions.RemoveEmptyEntries);
return server.GetStockQuotes(symbols);
}
}
CallbackHandler makes it super easy
to create a method on the server, pass data
to it via POST, QueryString or raw JSON/XML data, and then retrieve the results easily back in various formats. This works wonderful and I’ve used these tools in many projects for myself and with clients. But one thing missing has been the ability
to create clean URLs.
Typical URLs looked like this:
http://www.west-wind.com/WestwindWebToolkit/samples/Rest/StockService.ashx?Method=GetStockQuote&symbol=msfthttp://www.west-wind.com/WestwindWebToolkit/samples/Rest/StockService.ashx?Method=GetStockQuotes&symbolList=msft,intc,gld,slw,mwe&format=xml
which works and is clear enough, but also clearly very ugly. It would be much nicer if URLs could look like this:
http://www.west-wind.com//WestwindWebtoolkit/Samples/StockQuote/msfthttp://www.west-wind.com/WestwindWebtoolkit/Samples/StockQuotes/msft,intc,gld,slw?format=xml
(the Virtual Root in this sample is WestWindWebToolkit/Samples and StockQuote/{symbol} is the route)(If you use FireFox try using the JSONView plug-in make it easier
to view JSON content)
So, taking a clue from the WCF REST tools that use RouteUrls I set out
to create a way
to specify RouteUrls for each of the endpoints. The change made basically allows changing the above to:
[CallbackMethod(RouteUrl="RestService/StockQuote/{symbol}")]
public StockQuote GetStockQuote(string symbol)
{
StockServer server = new StockServer();
return server.GetStockQuote(symbol);
}
[CallbackMethod(RouteUrl = "RestService/StockQuotes/{symbolList}")]
public StockQuote[] GetStockQuotes(string symbolList)
{
StockServer server = new StockServer();
string[] symbols = symbolList.Split(new char[2] { ',',';' },StringSplitOptions.RemoveEmptyEntries);
return server.GetStockQuotes(symbols);
}
where a RouteUrl is specified as part of the Callback attribute. And with the changes made with RouteUrls I can now get URLs like the second set shown earlier.
So how does that work? Let’s find out…
How
to Create Custom Routes
As mentioned earlier Routing is made up of several steps:
Creating a custom RouteHandler
to create HttpHandler instances
Mapping the actual Routes
to the RouteHandler
Retrieving the RouteData and actually doing something useful with it in the HttpHandler
In the CallbackHandler routing example above this works out
to something like this:
Create a custom RouteHandler that includes a property
to track the method
to call
Set up the routes using Reflection against the class Looking for any RouteUrls in the CallbackMethod attribute
Add a RouteData property
to the CallbackHandler so we can access the RouteData in the code of the handler
Creating a Custom Route Handler
To make the above work I created a custom RouteHandler class that includes the actual IRouteHandler implementation as well as a generic and static method
to automatically register all routes marked with the [CallbackMethod(RouteUrl="…")] attribute.
Here’s the code:/// <summary>
/// Route handler that can create instances of CallbackHandler derived
/// callback classes. The route handler tracks the method name and
/// creates an instance of the service in a predictable manner
/// </summary>
/// <typeparam name="TCallbackHandler">CallbackHandler type</typeparam>
public class CallbackHandlerRouteHandler : IRouteHandler
{
/// <summary>
/// Method name that is
to be called on this route.
/// Set by the automatically generated RegisterRoutes
/// invokation.
/// </summary>
public string MethodName { get; set; }
/// <summary>
/// The type of the handler we're going
to instantiate.
/// Needed so we can semi-generically instantiate the
/// handler and call the method on it.
/// </summary>
public Type CallbackHandlerType { get; set; }
/// <summary>
/// Constructor
to pass in the two required components we
/// need
to create an instance of our handler.
/// </summary>
/// <param name="methodName"></param>
/// <param name="callbackHandlerType"></param>
public CallbackHandlerRouteHandler(string methodName, Type callbackHandlerType)
{
MethodName = methodName;
CallbackHandlerType = callbackHandlerType;
}
/// <summary>
/// Retrieves an Http Handler based on the type specified in the constructor
/// </summary>
/// <param name="requestContext"></param>
/// <returns></returns>
IHttpHandler IRouteHandler.GetHttpHandler(RequestContext requestContext)
{
IHttpHandler handler = Activator.CreateInstance(CallbackHandlerType) as IHttpHandler;
// If we're dealing with a Callback Handler
// pass the RouteData for this route
to the Handler
if (handler is CallbackHandler)
((CallbackHandler)handler).RouteData = requestContext.RouteData;
return handler;
}
/// <summary>
/// Generic method
to register all routes from a CallbackHandler
/// that have RouteUrls defined on the [CallbackMethod] attribute
/// </summary>
/// <typeparam name="TCallbackHandler">CallbackHandler Type</typeparam>
/// <param name="routes"></param>
public static void RegisterRoutes<TCallbackHandler>(RouteCollection routes)
{
// find all methods
var methods = typeof(TCallbackHandler).GetMethods(BindingFlags.Instance | BindingFlags.Public);
foreach (var method in methods)
{
var attrs = method.GetCustomAttributes(typeof(CallbackMethodAttribute), false);
if (attrs.Length < 1)
continue;
CallbackMethodAttribute attr = attrs[0] as CallbackMethodAttribute;
if (string.IsNullOrEmpty(attr.RouteUrl))
continue;
// Add the route
routes.Add(method.Name,
new Route(attr.RouteUrl, new CallbackHandlerRouteHandler(method.Name, typeof(TCallbackHandler))));
}
}
}
The RouteHandler implements IRouteHandler, and its responsibility via the GetHandler method is
to create an HttpHandler based on the route data.
When ASP.
NET calls GetHandler it passes a requestContext parameter which includes a requestContext.RouteData property. This parameter holds the current request’s route data as well as an instance of the current RouteHandler. If you look at GetHttpHandler() you can see that the code creates an instance of the handler we are interested in and then sets the RouteData property on the handler. This is how you can pass the current request’s RouteData
to the handler.
The RouteData object also has a RouteData.RouteHandler property that is also available
to the Handler later, which is useful in order
to get additional information about the current route. In our case here the RouteHandler includes a MethodName property that identifies the method
to execute in the handler since that value no longer comes from the URL so we need
to figure out the method name some other way. The method name is mapped explicitly when the RouteHandler is created and here the static method that auto-registers all CallbackMethods with RouteUrls sets the method name when it creates the routes while reflecting over the methods (more on this in a minute). The important point here is that you can attach additional properties
to the RouteHandler and you can then later access the RouteHandler and its properties later in the Handler
to pick up these custom values. This is a crucial feature in that the RouteHandler serves in passing additional context
to the handler so it knows what actions
to perform.
The automatic route registration is handled by the static RegisterRoutes<TCallbackHandler> method. This method is generic and totally reusable for any CallbackHandler type handler.
To register a CallbackHandler and any RouteUrls it has defined you simple use code like this in Application_Start (or other application startup code):protected void Application_Start(object sender, EventArgs e)
{
// Register Routes for RestService
CallbackHandlerRouteHandler.RegisterRoutes<RestService>(RouteTable.Routes);
}
If you have multiple CallbackHandler style services you can make multiple calls
to RegisterRoutes for each of the service types. RegisterRoutes internally uses reflection
to run through all the methods of the Handler, looking for CallbackMethod attributes and whether a RouteUrl is specified. If it is a new instance of a CallbackHandlerRouteHandler is created and the name of the method and the type are set.
routes.Add(method.Name, new Route(attr.RouteUrl, new CallbackHandlerRouteHandler(method.Name, typeof(TCallbackHandler) )) );
While the routing with CallbackHandlerRouteHandler is set up automatically for all methods that use the RouteUrl attribute, you can also use code
to hook up those routes manually and skip using the attribute. The code for this is straightforward and just requires that you manually map each individual route
to each method you want a routed:
protected void Application_Start(objectsender, EventArgs e){ RegisterRoutes(RouteTable.Routes);}void RegisterRoutes(RouteCollection routes)
{ routes.Add("StockQuote Route",new Route("StockQuote/{symbol}", new CallbackHandlerRouteHandler("GetStockQuote",typeof(RestService) ) ) ); routes.Add("StockQuotes Route",new Route("StockQuotes/{symbolList}", new CallbackHandlerRouteHandler("GetStockQuotes",typeof(RestService) ) ) );}I think it’s clearly easier
to have CallbackHandlerRouteHandler.RegisterRoutes() do this automatically for you based on RouteUrl attributes, but some people have a real aversion
to attaching logic via attributes. Just realize that the option
to manually create your routes is available as well.
Using the RouteData in the Handler
A RouteHandler’s responsibility is
to create an HttpHandler and as mentioned earlier, natively IHttpHandler doesn’t have any support for RouteData. In order
to utilize RouteData in your handler code you have
to pass the RouteData
to the handler.
In my CallbackHandlerRouteHandler when it creates the HttpHandler instance it creates the instance and then assigns the custom RouteData property on the handler:IHttpHandler handler = Activator.CreateInstance(CallbackHandlerType) as IHttpHandler;
if (handler is CallbackHandler)
((CallbackHandler)handler).RouteData = requestContext.RouteData;
return handler;
Again this only works if you actually add a RouteData property
to your handler explicitly as I did in my CallbackHandler implementation:/// <summary>
/// Optionally store RouteData on this handler
/// so we can access it internally
/// </summary>
public RouteData RouteData {get; set; }
and the RouteHandler needs
to set it when it creates the handler instance.
Once you have the route data in your handler you can access Route Keys and Values and also the RouteHandler. Since my RouteHandler has a custom property for the MethodName
to retrieve it from within the handler I can do something like this now
to retrieve the MethodName (this example is actually not in the handler but target is an instance pass
to the processor): // check for Route Data method name
if (target is CallbackHandler)
{
var routeData = ((CallbackHandler)target).RouteData;
if (routeData != null)
methodToCall = ((CallbackHandlerRouteHandler)routeData.RouteHandler).MethodName;
}
When I need
to access the dynamic values in the route ( symbol in StockQuote/{symbol}) I can retrieve it easily with the Values collection (RouteData.Values["symbol"]). In my CallbackHandler processing logic I’m basically looking for matching parameter names
to Route parameters:
// look for parameters in the routeif(routeData != null){ string parmString = routeData.Values[parameter.Name] as string; adjustedParms[parmCounter] = ReflectionUtils.StringToTypedValue(parmString, parameter.ParameterType);}
And with that we’ve come full circle. We’ve created a custom RouteHandler() that passes the RouteData
to the handler it creates. We’ve registered our routes
to use the RouteHandler, and we’ve utilized the route data in our handler.
For completeness sake here’s the routine that executes a method call based on the parameters passed in and one of the options is
to retrieve the inbound parameters off RouteData (as well as from POST data or QueryString parameters):internal object ExecuteMethod(string method, object target, string[] parameters, CallbackMethodParameterType paramType, ref CallbackMethodAttribute callbackMethodAttribute)
{
HttpRequest Request = HttpContext.Current.Request;
object Result = null;
// Stores parsed parameters (from string JSON or QUeryString Values)
object[] adjustedParms = null;
Type PageType = target.GetType();
MethodInfo MI = PageType.GetMethod(method, BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic);
if (MI == null)
throw new InvalidOperationException("Invalid Server Method.");
object[] methods = MI.GetCustomAttributes(typeof(CallbackMethodAttribute), false);
if (methods.Length < 1)
throw new InvalidOperationException("Server method is not accessible due
to missing CallbackMethod attribute");
if (callbackMethodAttribute != null)
callbackMethodAttribute = methods[0] as CallbackMethodAttribute;
ParameterInfo[] parms = MI.GetParameters();
JSONSerializer serializer = new JSONSerializer();
RouteData routeData = null;
if (target is CallbackHandler)
routeData = ((CallbackHandler)target).RouteData;
int parmCounter = 0;
adjustedParms = new object[parms.Length];
foreach (ParameterInfo parameter in parms)
{
// Retrieve parameters out of QueryString or POST buffer
if (parameters == null)
{
// look for parameters in the route
if (routeData != null)
{
string parmString = routeData.Values[parameter.Name] as string;
adjustedParms[parmCounter] = ReflectionUtils.StringToTypedValue(parmString, parameter.ParameterType);
}
// GET parameter are parsed as plain string values - no JSON encoding
else if (HttpContext.Current.Request.HttpMethod == "GET")
{
// Look up the parameter by name
string parmString = Request.QueryString[parameter.Name];
adjustedParms[parmCounter] = ReflectionUtils.StringToTypedValue(parmString, parameter.ParameterType);
}
// POST parameters are treated as methodParameters that are JSON encoded
else
if (paramType == CallbackMethodParameterType.Json)
//string newVariable = methodParameters.GetValue(parmCounter) as string;
adjustedParms[parmCounter] = serializer.Deserialize(Request.Params["parm" + (parmCounter + 1).ToString()], parameter.ParameterType);
else
adjustedParms[parmCounter] = SerializationUtils.DeSerializeObject(
Request.Params["parm" + (parmCounter + 1).ToString()],
parameter.ParameterType);
}
else
if (paramType == CallbackMethodParameterType.Json)
adjustedParms[parmCounter] = serializer.Deserialize(parameters[parmCounter], parameter.ParameterType);
else
adjustedParms[parmCounter] = SerializationUtils.DeSerializeObject(parameters[parmCounter], parameter.ParameterType);
parmCounter++;
}
Result = MI.Invoke(target, adjustedParms);
return Result;
}
The code basically uses Reflection
to loop through all the parameters available on the method and tries
to assign the parameters from RouteData, QueryString or POST variables. The parameters are converted into their appropriate types and then used
to eventually make a Reflection based method call.
What’s sweet is that the RouteData retrieval is just another option for dealing with the inbound data in this scenario and it adds exactly two lines of code plus the code
to retrieve the MethodName I showed previously – a seriously low impact addition that adds a lot of extra value
to this endpoint callback processing implementation.
Debugging your Routes
If you create a lot of routes it’s easy
to run into Route conflicts where multiple routes have the same path and overlap with each other. This can be difficult
to debug especially if you are using automatically generated routes like the routes created by CallbackHandlerRouteHandler.RegisterRoutes.
Luckily there’s a tool that can help you out with this nicely. Phill Haack created a RouteDebugging tool you can download and add
to your project. The easiest way
to do this is
to grab and add this
to your project is
to use NuGet (Add Library Package from your Project’s Reference Nodes):
which adds a RouteDebug assembly
to your project.
Once installed you can easily debug your routes with this simple line of code which needs
to be installed at application startup:protected void Application_Start(object sender, EventArgs e)
{
CallbackHandlerRouteHandler.RegisterRoutes<StockService>(RouteTable.Routes);
// Debug your routes
RouteDebug.RouteDebugger.RewriteRoutesForTesting(RouteTable.Routes);
}
Any routed URL then displays something like this:
The screen shows you your current route data and all the routes that are mapped along with a flag that displays which route was actually matched. This is useful – if you have any overlap of routes you will be able
to see which routes are triggered – the first one in the sequence wins.
This tool has saved my ass on a few occasions – and with NuGet now it’s easy
to add it
to your project in a few seconds and then remove it when you’re done.
Routing Around
Custom routing seems slightly complicated on first blush due
to its disconnected components of RouteHandler, route registration and mapping of custom handlers. But once you understand the relationship between a RouteHandler, the RouteData and how
to pass it
to a handler, utilizing of Routing becomes a lot easier as you can easily pass context from the registration
to the RouteHandler and through
to the HttpHandler. The most important thing
to understand when building custom routing solutions is
to figure out how
to map URLs in such a way that the handler can figure out all the pieces it needs
to process the request. This can be via URL routing parameters and as I did in my example by passing additional context information as part of the RouteHandler instance that provides the proper execution context. In my case this ‘context’ was the method name, but it could be an actual static value like an enum identifying an operation or category in an application. Basically user supplied data comes in through the url and static application internal data can be passed via RouteHandler property values.
Routing can make your application URLs easier
to read by non-techie types regardless of whether you’re building Service type or REST applications, or full on Web interfaces. Routing in ASP.
NET 4.0 makes it possible
to create just about any extensionless URLs you can dream up and custom RouteHanmdler
References
Sample ProjectIncludes the sample CallbackHandler service discussed here along with compiled versionsof the Westwind.Web and Westwind.Utilities assemblies. (requires .
NET 4.0/VS 2010)
West Wind Web Toolkit includes full implementation of CallbackHandler and the Routing Handler
West Wind Web Toolkit Source CodeContains the full source code
to the Westwind.Web and Westwind.Utilities assemblies usedin these samples. Includes the source described in the post.(Latest build in the Subversion Repository)
CallbackHandler Source(Relevant code
to this article tree in Westwind.Web assembly)
JSONView FireFoxPluginA simple FireFox Plugin
to easily view JSON data natively in FireFox.For IE you can use a registry hack
to display JSON as raw text.© Rick Strahl, West Wind Technologies, 2005-2011Posted in ASP.NET AJAX HTTP
