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
