I'm using the FromUri attribute to bind query string parameters to a custom model in a Web Api application.
There are 2 scenarios where I found the error message returned by the ApiController's ModelState is empty.
This happens when I enter the value '#' for a nullable integer and when I enter 2 identical parameters into the query string.
I'm expecting a meaningful message to be returned e.g. "The value '#' is not valid for NullableInteger" and "Duplicate entries in query string".
Comments: The first scenario (Nullable Integers) does seem a bit intriguing and if you're able to provide a reliable repro scenario that does not match the expectations as I explained earlier, I'd be happy to look at it again. If it does match the scenarios I'd pointed we'd be unable to change it as it would be a breaking change. We'll be tracking the model binding issue in the second scenario (multiple parameters) separately, but the behavior would be similar to Mvc - we'll silently consume the first parameter value. There are extensibility points in WebAPI that would allow you to change this behavior, but doing this isn’t pretty today – you’ll have to create a subclass of ValueProviderResult (https://aspnetwebstack.codeplex.com/SourceControl/latest#src/System.Web.Http/ValueProviders/ValueProviderResult.cs) and override the Convert method on it. You’ll have to copy a bunch of code from the existing type and change the behavior of ConvertSimpleType and UnwrapPossibleListType to throw when you run into the scenarios you care. Injecting your custom ValueProviderResult would require replacing the QueryStringValueProviderFactory.
There are 2 scenarios where I found the error message returned by the ApiController's ModelState is empty.
This happens when I enter the value '#' for a nullable integer and when I enter 2 identical parameters into the query string.
I'm expecting a meaningful message to be returned e.g. "The value '#' is not valid for NullableInteger" and "Duplicate entries in query string".
Comments: The first scenario (Nullable Integers) does seem a bit intriguing and if you're able to provide a reliable repro scenario that does not match the expectations as I explained earlier, I'd be happy to look at it again. If it does match the scenarios I'd pointed we'd be unable to change it as it would be a breaking change. We'll be tracking the model binding issue in the second scenario (multiple parameters) separately, but the behavior would be similar to Mvc - we'll silently consume the first parameter value. There are extensibility points in WebAPI that would allow you to change this behavior, but doing this isn’t pretty today – you’ll have to create a subclass of ValueProviderResult (https://aspnetwebstack.codeplex.com/SourceControl/latest#src/System.Web.Http/ValueProviders/ValueProviderResult.cs) and override the Convert method on it. You’ll have to copy a bunch of code from the existing type and change the behavior of ConvertSimpleType and UnwrapPossibleListType to throw when you run into the scenarios you care. Injecting your custom ValueProviderResult would require replacing the QueryStringValueProviderFactory.