Routes with similar query string params are not distinguished correctly

[darrensteadman]

I have the following two URLs that I am trying to convert over from Web API 2 to MVC6

api/values/123?page=1&pageSize=10
api/values/123?from=2016-06-01T00:00:00&to=2016-06-02T00:00:00&page=1&pageSize=10

I have the following route attributes set

[Route("values/{id}/{page:int?}/{pageSize:int?}")]
[Route("values/{id}/{from?}/{to?}/{page:int?}/{pageSize:int?}")]

The issue is the two URLs always end up resolving to the same route. It would appear that I can no longer specify a unique route using the query string parameters as I used to be able to do. Also if I remove the optionals from the query string the handlers don't get hit at all.

I have also tried setting the Order value on the Route attribute and all that does is send both requests to whichever route has the priority.

If I change my URLs to

api/values/123/1/10
api/values/123/2016-06-01T00:00:00/2016-06-02T00:00:00/1/10

Then everything works fine, so it would appear that it's only a problem if query strings are being used. The issue I have is this is an API for an existing product that people have developed against and they will be using the query string URL format.

I am using the official RC2 release for this.

[dougbu]

Routing is based on the URI's path and not the query string. You need a custom routing constraint that rejects matches based on the routeContext.HttpContext.Request.QueryString or ...Query.

[darrensteadman]

Could you point me in the direction of the documentation for this?

Why has the behavior changed from Web API 2?

[dougbu]

Please see documentation at https://docs.asp.net/en/latest/fundamentals/routing.html?highlight=constraint#route-constraints for an overview.

Implement the IRouteConstraint interface when defining a custom constraint. https://github.com/aspnet/Routing/tree/dev/src/Microsoft.AspNetCore.Routing/Constraints contains a few out-of-the-box constraints. The https://github.com/aspnet/Entropy/tree/dev/samples/Mvc.InlineConstraintSample.Web sample includes a custom constraint.

Why has the behavior changed from Web API 2?

What exactly worked in Web API 2? Values from the query string wouldn't match a template in that framework either.

Please upload a sample of the exact Web API 2 code you're trying to match in ASP.NET Core MVC.

[darrensteadman]

I have created a quick sample app to show the difference. Hopefully you'll be able to see what I'm doing wrong.

https://github.com/darrensteadman/WebAPIDiff

If you go into the old web api folder and open the solution it includes both projects.

Old Web API is using Web API 2
New Web API is using asp.net core RC2

I have a very simple ValuesController in each project it has two Get functions each of which takes a different number of arguments and returns a basic string with them concatenated together.

If you run both of the projects and set the following URLs

http://localhost:yourport/values/get/astring?from=2016-01-01&to=2016-01-02&page=1&pageSize=10

http://localhost:yourport/values/get/astring?page=1&pageSize=10

The first one should present a string with the word astring and then the dates and the other values all put together, the second url should give you the string astring with the other values put together. Notice how if you put break points into the controller you will see the correct URL fires the correct handler.

If you do the same with the New API project then all that happens is the first handler that was defined in the file always gets hit regardless of the URL. Note also on the route I have to mark the majority of the variables as optional or it won't match what so ever.

[javiercn]

Web API does overload resolution for actions based on query string parameters, ASP.NET Mvc does not, I believe that's why you see different results. @rynowak can provide more details

[darrensteadman]

In which case how would you recommend I recreate the same behavior in ASP.NET core?

[dougbu]

@darrensteadman your original question was specifically about attribute routing. However your "Old Web API" project is using conventional routing, including a few conventions we haven't pulled into ASP.NET Core MVC.

In any case you have a few options.

1. Add a custom routing constraint that rejects matches based on the routeContext.HttpContext.Request.QueryString or ...Query.
2. Change the route attributes in "NewWebApi"'s ValuesController to a single [Route("[controller]/[action]")] on the controller. Add "Microsoft.AspNetCore.Mvc.WebApiCompatShim": "1.0.0-rc2-final" to the dependencies in project.json and restore the packages. Change your AddMvc() call to services.AddMvc(options => options.Conventions.Add(new WebApiOverloadingApplicationModelConvention())); in your Startup.ConfigureServices() method. And apply [UseWebApiOverloading] to the ValuesController. (Not sure but it may help to apply [UseWebApiParameterConventions] as well.)
3. Change the route attributes as in 2. Then apply a custom convention and attribute similar to WebApiOverloadingApplicationModelConvention and [UseWebApiOverloading]. This avoids using the Web API compatibility shim.

[dougbu]

Side note: The [Route()] change just avoids having two distinct templates match a request. In 2. and 3., you want action selection to make the final choice.

[darrensteadman]

Thanks for the help, I'll have to assess what will be best for us and go from there.