[.NET 10] Emphasize scope of `AddValidation()` on built-in validation support for minimal APIs

[erwinkramer]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

No response

Describe the solution you'd like

It might be useful to emphasize at https://learn.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-10.0?view=aspnetcore-9.0#enable-built-in-validation-support-for-minimal-apis that UnmappedMemberHandling by default is set to Skip, even when adding builder.Services.AddValidation();. This might seem strange when you assume that adding the validation service will just validate the whole incoming JSON with the object type.

To take things further, it might even make more sense to call it AddAnnotationValidation instead of AddValidation because it's really scoped to a small part, and it isn't responsible for all the validation, like unmatched (query) parameters, or enums.

Additional context

No response

[captainsafia]

@erwinkramer Thanks for filing this issue -- I agree that the docs can be clearer here.

This touches at a larger issue that's been discussed in the context of this validation work. As you observed, validation happens after deserialization and the validation layer is meant to operate independently of the serialization layer. That means that "validations" that are typically done by System.Text.Json like requiredness checks and the UnmappedMemberHandling. Issues like dotnet/aspnetcore#62202 touch on this topic as well.

To properly resolve this, we'd need to add some logic at the Minimal API layer to (a) recognize that the validation filter is in-effect and (b) intercept the exceptions that STJ throws when it encounters invalid validation errors during serialization.

Note: this wouldn't solve the UnmappedMemberHandling problem since in that case the validation layer doesn't even seen the skipped values since they were never deserialized into the object.

WRT to the naming, although the built-in implementation builds on top of the DataAnnotations attributes on model, it's possible to extend the validation layer to support alternative validation strategies.