Enum as API method's parameter ignoring naming policy when binding

[johnwc]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

We have an Enum as one of the method's parameters. We also have a specific naming policy for that Enum. All the API responses that contain the Enum are getting formatted correctly as kebab naming within the JSON responses. But, when used as a parameter the binding fails to use the correct converter, it only works if the name is formatted as the default naming policy.

Expected Behavior

The binding for the parameters utilize the same naming policy that the Enum is configured for.

Steps To Reproduce

Configure specific Enum with custom naming policy.

.AddJsonOptions(options =>
{
    ...
    options.JsonSerializerOptions.Converters.Add(new JsonStringEnumConverter<Providers>(System.Text.Json.JsonNamingPolicy.KebabCaseLower));
    options.JsonSerializerOptions.Converters.Add(new JsonStringEnumConverter(System.Text.Json.JsonNamingPolicy.CamelCase));
    options.JsonSerializerOptions.Converters.Add(new Core.Converters.DateOnlyJsonConverter());
});

Use Enum as type of a parameter.

[HttpPost("{provider}/unlink", Name = "Unlink")]
public async Task<ActionResult<BooleanResponse>> Unlink(Providers provider)
{
    ...
}

public enum Providers
{
    ProviderOne,
    ProviderTwo,
    ProviderThree,
}

Exceptions (if any)

When calling api endpoint as https://example.com/provider-one/unlink the server responds with 400.
When calling api endpoint as https://example.com/providerOne/unlink the method gets executed and the server responds with 200.

.NET Version

8.0.303

Anything else?

No response

[captainsafia]

@johnwc Thanks for filing this issue!

The behavior that you are seeing is a result of the difference in behavior when binding from a route (where System.Text.Json is not involved) vs. binding from the body (whre System.Text.Json is involved). You'll observe the correct behavior when deserializing requests/serializing responses because the converters that you've applied to your JSON options are at play. The same is not the case when you try to bind from the string-based route.

Your best bet in this case might be to use a custom model binder to support binding rules for Providers in this way. You can find the docs for that here.

[johnwc]

@captainsafia How am I supposed to create a custom model binding for a route? The route parameters are not models. I opened this ticket to open the awareness of it not using the correct converter, for it to get out in front of your team to figure out how to get the framework updated to correct the issue. As I am not aware, nor could I find anything on how to control what converter is used for route parameters.

Update:
Reading much further down in the link you shared, I see how you are trying to point out how to do this. But this seems like and extreme overkill to have to create a model binder for a simple Enum converter. Especially when the functionally already exists but using the standard EnumToStringConverter.

[dotnet-policy-service]

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.

[johnwc]

@captainsafia @dotnet-policy-service Reopen
This has not been answered...

[captainsafia]

Reading much further down in the link you shared, I see how you are trying to point out how to do this. But this seems like and extreme overkill to have to create a model binder for a simple Enum converter. Especially when the functionally already exists but using the standard EnumToStringConverter.

Unfortunately, that's a requirement at the moment, AFAIK. The EnumToStringConverter functionality that you mentioned is a feature that specifically exists within the context of the JSON serializer, which is not in use when binding from simple sources like route and query parameters.

It's unlikely that we'll introduce a new feature specifically for this given the custom model binders fulfill that role currently.

[johnwc]

There are lots of ways of doing things differently but with the same outcome within almost all languages, but we don't eliminate them all except one possible way. This is a request to have this built into the framework so to help keep things simple on the developer's side, can you please reopen this ticket as it is a feature request for future versions of ASP.Net?