Tutorial and Tool written by Troy Dai with assistance from Rick Anderson (Twitter @RickAndMSFT)
Search for “asp.net web api routing” on stackoverflow, you’ll find many questions. How exactly does Web API routing work? Why doesn’t my route work? Why is this action not invoked? Often time it is difficult to debug route debugger.
To address this issue I wrote this tool named “ASP.NET Web API Route Debugger” trying to make Web API developers’ lives a bit easier.
In this article I’ll first introduce how to set up route debugger. Then I’ll introduce how routing works in Web Api. It is followed by three examples of how to use the route debugger in real cases.
How to Step up Route Debugger
You can install Route Debugger from NuGet (http://www.nuget.org/packages/WebApiRouteDebugger/)
PM> Install-Package WebApiRouteDebugger
The NuGet package will add a new area and to your project. The image below shows the new files added to the project. (The + icon shows new files and the red check icon shows changed files)
Hit F5 to compile and then navigate to http:// localhost:xxx/rd for the route debugger page.
Enter the URL you want to test and press Send. The results page is displayed.
I’ll explain how to read the results in the following sections.
How Routing works in ASP.NET Web Api
The routing mechanism of ASP.NET Web API is composed of three steps: find the matching route and parse the route data, find the matching controller, and find the matching action. In any step fails to find a selection the steps following will not be executed. For example, if no controller is found, the matching ends and no action is looked for.
In the first step, a route will be matched. Every route is defined with route template, defaults, constraints, data tokens and handler. (Routes are configured by default in App_Start\WebApiConfig.cs ) Once a route is matched, the request URL is parsed into route data based on the route template. Route data is a dictionary mapping from string to object.
Controller matching is purely done based on the value of “controller” key in route data. If the key “controller” doesn’t exist in route data, controller selection will fail.
After controller is matched, all the public methods on the controller are found through reflection. To match the action, it uses the following algorithm:
1. If route data contains key “action”, then the action will be searched based on action name. Unlike ASP.NET MVC, Web API routes generally do not use action names in routing.
a. Find all actions where the action name is “action” in the route data;
b. Each action supports one or more HTTP Verbs (GET, POST, PUT, etc.). Eliminate those actions which don’t support the current HTTP request’s verb.
2. If the route data doesn’t contains key “action”, then the action will be searched based on the supported request method directly.
3. For selected actions in either of above two steps, examine the parameters of action method. Eliminate those actions that don’t match all the parameters in the route data.
4. Eliminate all actions that are marked by the NonAction attribute.
If more than one action matches, an HTTP 500 error is thrown. (Internally an HttpResponseException is thrown.)
If there is no matching action, an HTTP 404 error is thrown.
How to use Route bugger
Example 1: Missing Controller Value
Source: http://stackoverflow.com/questions/13876816/web-api-routing
The ISsue
The controller and routes are shown below. The URL
localhost/api/machine/somecode/all
doesn’t match the MachineApi route.
Download Sample1 and install the route debugger NuGet package to follow along.
Controller
public class MachineController : ApiController
{
public IEnumerable
{
return new List
{
new Machine
{
LastPlayed = DateTime.UtcNow,
MachineAlertCount = 1,
MachineId = "122",
MachineName = "test",
MachinePosition = "12",
MachineStatus = "test"
}
};
}
public IEnumerable
{
return new List
{
new Machine
{
LastPlayed = DateTime.UtcNow,
MachineAlertCount = 1,
MachineId = "122",
MachineName = "test",
MachinePosition = "12",
MachineStatus = "test"
}
};
}
}
Route
config.Routes.MapHttpRoute(
name: "MachineApi",
routeTemplate: "api/machine/{code}/all"
);
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
Test
Test http://localhost/api/machine/somecode/all in the route debugger:
Observation
1. The HTTP status code is 404 (resource not found);
2. The route data contains only one key value pair, mapping “Somecode” to “Code”
3. The selected route is “Api/Machine/{Code}/All” because the template fits the URL. However there are no default values defined for this route.
4. No controller matches (none of the rows are highlighted in controller selecting table)
Analysis
The route debugger output shows the “controller” value is not found in the route data or route defaults. The default controller selector relies on “controller” value to find a proper controller.
A common misunderstanding of route templates is that the values are mapped based on their position. That’s not true. In this case even though Machine is placed right after Api, there is no hint that this segment of URL should be picked up.
Solution
Add a default value specifying the machine controller to the first route:
config.Routes.MapHttpRoute(
name: "MachineApi",
routeTemplate: "api/machine/{code}/all",
defaults: new { controller = "Machine" });
After this change, you get an HTTP 200 return, the machine controller is matched and the Action is matched. The matching route, controller and action are highlighted in green in the route debugger as shown below.
Similar issueS:
Example 2: Ambiguous default
Source: http://stackoverflow.com/questions/14058228/asp-net-web-api-no-action-was-found-on-the-controller
Reproduce the issue
The controller and routes are shown below.
Controller
public class ValuesController : ApiController
{
// GET api/values
public IEnumerable
{
return new string[] { "value1", "value2" };
}
// GET api/values/5
public string Get(int id)
{
return "value";
}
// POST api/values
public void Post([FromBody]string value)
{
}
// PUT api/values/5
public void Put(int id, [FromBody]string value)
{
}
// DELETE api/values/5
public void Delete(int id)
{
}
[HttpGet]
public void Machines()
{
}
public void Machines(int id)
{
}
}
Route definition
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{action}/{id}",
defaults: new { action = "get", id = RouteParameter.Optional });
TEST
Try the following three routes which work correctly
· /api/Values
· /api/Values/Machines
· /api/Values/Machine/100
The URL /api/Values/1 Returns a 404 error.
Observation
1. In the route data section you can see “action” is mapped to “1”, the third segment in the URL. It is a restriction assignment since the selected route is api/{controller}/{action}/{id}
2. Note that although the default mapping of “action” is “get”, the value “1” is assigned for the action, not the value “1”.
3. The Values Controller is selected.
4. The Action selecting table has no match. The “By Action Name” column is filled with “False”, which means all actions are rejected because their action names are not matched to the “action” value in route data.
Analysis
There are two pivots here.
1. The route data will always prefer the value in URL over the default value if a URL value can be found. In all of the four URLs listed above, none of them matches the default “action” mapping. In all four URLs, the route data contains the action key and action value.
2. Because the “action” value exists in the route data, the action selector will pick the action from the route data.
The route debugger tool shows that with the URL http://localhost:xxx/api/values/1, “1” is the action name and no such action exits.
Solution
Use one strategy of action matching, either by action name or by verb. Don’t put both in one controller and one route.
Example 3: Ambigous Action
Source: Why don’t my routes find the appropriate action? http://stackoverflow.com/questions/14614516/my-web-api-route-map-is-returning-multiple-actions
Reproduce The Issue
The URL cause 500 is http://localhost/api/access/blob
Controller
public class AccessController : ApiController
{
// GET api/access/blob
[HttpGet]
public string Blob()
{
return "blob shared access signature";
}
// GET api/access/queue
[HttpGet]
public string Queue()
{
return "queue shared access signature";
}
}
Route definition
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
config.Routes.MapHttpRoute(
name: "AccessApi",
routeTemplate: "api/{controller}/{action}"
);
Observation
1. There are two routes and the URL matches both routes. The first one is selected because Web API routing selects the first route that matches (Greedy matching).
2. The first route template doesn't contain {action}, there isn’t “action” value in route data, therefore the action will be selected based on HTTP verb
3. Controller selecting successfully matches the Access controller.
4. Two actions are selected using the only available matching criteria, the HTTP verb GET
Analylsis
The root problem is that both routes match and the first one is picked while the developer was expecting the second route to match. The “action” name is ignored and eventually action selector tries to match action based on verb alone.
Solution
Two solutions:
1. Move the default route to the end.
2. Delete default route.
The greedy route selection can lead to difficult to resolve errors, especially when you assume the wrong route was selected. The route debugger is especially useful for this problem, as it shows you the route template selected.
Conclusion
Web API routing problems can get tricky and be difficult to diagnose. The Route Debugger tool can help you find routing problems and understand how routing works. We plan to address routing problems in the future (at least partially) with Attribute routing in Web API.
Source Code
The tool is open source. You can also download the source to the route debugger http://aspnet.codeplex.com. Click the Source Code tab and expand Tools\WebApi\RouteDebugger.
Resources
· Routing and Action Selection
Acknowledgments
· Rick Anderson (Twitter @RickAndMSFT)
· Mike Wasson