Minimal API Validation should respect [JsonPropertyName]

[martincostello]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Related to #61764.

If a parameter bound to a Minimal API endpoint from the request body uses explicit [JsonPropertyName] attributes to control serialization, this value is not used to generate responses when validation fails.

aspnetcore/src/Validation/gen/Parsers/ValidationsGenerator.TypesParser.cs

Lines 201 to 203 in 89bd338

	Name: correspondingProperty.Name,
	DisplayName: parameter.GetDisplayName(wellKnownTypes.Get(WellKnownTypeData.WellKnownType.System_ComponentModel_DataAnnotations_DisplayAttribute)) ??
	correspondingProperty.GetDisplayName(wellKnownTypes.Get(WellKnownTypeData.WellKnownType.System_ComponentModel_DataAnnotations_DisplayAttribute)),

For example a model property such as this:

[JsonPropertyName("plaintext")]
[Required]
public string Plaintext { get; set; } = string.Empty;

Generates an error such as the below when absent from a request:

{
  "title": "One or more validation errors occurred.",
  "errors": {
    "Plaintext": [
      "The Plaintext field is required."
    ]
  }
}

It's possible to override the value in the message using [Display] (at the cost of additional duplication), but it isn't possible to override the error property name:

+ [Display(Name = "plaintext")]
  [JsonPropertyName("plaintext")]
  [Required]
  public string Plaintext { get; set; } = string.Empty;

Expected Behavior

The Name value of [JsonPropertyName] is used as the default for the Name and DisplayName values if not overridden by [Display] (or some other mechanism that should take precedence) to generate a response like the following:

{
  "title": "One or more validation errors occurred.",
  "errors": {
    "plaintext": [
      "The plaintext field is required."
    ]
  }
}

Steps To Reproduce

1. Clone martincostello/api@5891d85
2. Run build.ps1 in the root of the repository.

Exceptions (if any)

No response

.NET Version

10.0.100-preview.7.25380.108

Anything else?

No response

[captainsafia]

@martincostello I'm personally not opposed to this in practice although there have been philosophical debates about how deeply we want to integrate STJ-specific behaviors in the validations resolver (which is meant to be generic and not depend on a particular serializer).

The ship has already sailed in this regard with the logic I introduced in the original implementation for handling of [JsonDerivedType] although I think there's some motivation to not include more of these patterns especially as we begin to use the shared logic in more places.

[martincostello]

I think for me it's exposing an implementation detail either way.

If the message refers to a Reference field but the field in the payload the client is expected to send is called, say, $ref, then that's leaking an implementation detail to the client.

It's possible to override with [Display], but that quickly becomes a lot of extra boilerplate.

Using the names the client "sees" makes more sense to me in lieu of something more specific.

[captainsafia]

It's possible to override with [Display], but that quickly becomes a lot of extra boilerplate.

Yep, because the Display attribute exists as an option here (although not ideal) I considered it a non-blocker.

As far as this change, I'm thinking that we can merge it for .NET 11 given where we are in the release cycle and consider a backport if it proves important for .NET 10.

[desjoerd]

For the error keys, this is maybe something which can be "patched" in the ValidationEndpointFilterFactory.cs. Because then you could have more hooks to get the JsonType info and set those properties based on the json settings. This would keep the Microsoft.Extensions.Validation generic.

In that location you will know which parameter causes the error, see what the source is (body, query, header etc..) and resolve the correct metadata/mapping for it.

This of-course does not work for the displayname in the message.