Model validation and problem details

ASP.NET Core's built-in validation is data annotations, from System.ComponentModel.DataAnnotations:

public class CreateUser
{
    [Required] public string? Name { get; set; }
    [EmailAddress] public string? Email { get; set; }
    [Range(18, 120)] public int? Age { get; set; }
    [MaxLength(5)] public string? Code { get; set; }
}

In a controller marked [ApiController], model binding runs these attributes and, if any fail, the action never executes: the framework answers 400 with a ValidationProblemDetails body. Minimal APIs in .NET 9 do not validate for you; you call a validator yourself, usually from an endpoint filter. (.NET 10 adds opt-in validation for minimal APIs; this course targets .NET 9.)

Data annotations live in the base class library, so the example runs the real Validator, not a model of it.

1using System.ComponentModel.DataAnnotations;2 3public class CreateUser4{5    [Required] public string? Name { get; set; }6    [EmailAddress] public string? Email { get; set; }7    [Range(18, 120)] public int? Age { get; set; }8    [MaxLength(5)] public string? Code { get; set; }9}10 11public static class Solution12{13    static string Check(string label, CreateUser user, bool all)14    {15        var results = new List<ValidationResult>();16        var ok = Validator.TryValidateObject(user, new ValidationContext(user), results, validateAllProperties: all);17        return label + (ok ? ": valid" : ": " + string.Join(" | ", results.Select(r => r.ErrorMessage)));18    }19 20    public static List<string> Run()21    {22        var bad = new CreateUser { Name = "  ", Email = "not-an-email", Age = 7, Code = "TOOLONG" };23        var sparse = new CreateUser { Name = "Ann" };24        return new List<string>25        {26            Check("bad, default", bad, all: false),27            Check("bad, all properties", bad, all: true),28            Check("sparse, all properties", sparse, all: true),29        };30    }31}

Two things in that output surprise people. TryValidateObject with its default validateAllProperties: false checks only [Required]; pass true to run every attribute. And the second user, whose email, age and code are all null, is valid: [Range], [EmailAddress] and [MaxLength] all accept null. Only [Required] rejects a missing value, so a field that must be present and in range needs both attributes.

Cross-field rules

A rule involving two properties goes in IValidatableObject.Validate. It runs only after every property attribute has passed.

1using System.ComponentModel.DataAnnotations;2 3public class Booking : IValidatableObject4{5    [Required] public string? Guest { get; set; }6    public DateTime From { get; set; }7    public DateTime To { get; set; }8 9    public IEnumerable<ValidationResult> Validate(ValidationContext context)10    {11        if (To <= From) yield return new ValidationResult("To must be after From.", new[] { nameof(To) });12    }13}14 15public static class Solution16{17    static string Check(Booking b)18    {19        var results = new List<ValidationResult>();20        Validator.TryValidateObject(b, new ValidationContext(b), results, validateAllProperties: true);21        return results.Count == 0 ? "valid" : string.Join(" | ", results.Select(r => r.ErrorMessage));22    }23 24    public static List<string> Run()25    {26        var backwards = new DateTime(2025, 5, 1);27        return new List<string>28        {29            Check(new Booking { Guest = null, From = backwards, To = backwards.AddDays(-2) }),30            Check(new Booking { Guest = "Ann", From = backwards, To = backwards.AddDays(-2) }),31            Check(new Booking { Guest = "Ann", From = backwards, To = backwards.AddDays(2) }),32        };33    }34}

The response

A failed validation is returned in the problem details format (application/problem+json, RFC 9457, which replaced RFC 7807): status, title, and an errors object mapping each field name to an array of messages. Grouping is per field, so one field can carry several messages. Calling builder.Services.AddProblemDetails() makes the exception handler and status code pages produce the same format for other errors, so clients parse one shape everywhere. A trimmed example (the real body also carries type and traceId):

{
  "title": "One or more validation errors occurred.",
  "status": 400,
  "errors": { "Age": ["The field Age must be between 18 and 120."] }
}

Common mistakes

• Relying on [Range] or [EmailAddress] alone for a field that must be present. Null passes; add [Required].
• Declaring the property as a non-nullable int and adding [Required]. A missing JSON property binds as 0, which [Required] accepts; use int?.
• Calling Validator.TryValidateObject without and concluding the model is valid.