AddProblemDetailsConventions changes HTTP 400 to 422

Without AddProblemDetailsConventions, a request with an invalid model returns HTTP response code 400. With AddProblemDetailsConventions, the same request returns 422.

Possibly related to #125.

[khellang]

See https://github.com/khellang/Middleware/issues/149#issuecomment-1022156162.

You can set ValidationProblemStatusCode back to 400 of you want:

https://github.com/khellang/Middleware/blob/a81989f16c83c286d1c2fee2e956b27b3243663b/src/ProblemDetails/ProblemDetailsOptions.cs#L133-L136

[kjkrum]

There’s a domain-specific language layered on top of the JSON. The syntax of that language is expressed in the semantic content of the JSON. Model binding and validation are responsible for validating that syntax. Model binding and validation are in absolutely no way concerned with the semantic content of that language. From the perspective of the controller and service layers, as well as the client, any error that occurs during model binding and validation is a syntax error. This is the sense in which “syntax” should be understood in RFC4918. Logically, this inevitably follows from recognizing that the schema is a language. Pragmatically, it creates an elegant separation of concerns that is neatly reflected in the response codes.

Normalizing returning 422 for errors in model binding and validation will harm the Internet.