Support custom error messages when validation fails on minimal APIs

[captainsafia]

This issue captures user feedback from https://twitter.com/davidfowl/status/1428228518953984005?s=20.

Currently, the feature to support treating parameters that are nullable or have default values as optional will return a status code and no error message as part of the response. This is largely because (1) it builds on top of the existing try-parse parsing logic which does nothing and (2) when we were working through the feature we had punted on the problem of what message to send back.

Users want to be be able to customize the message to:

• Provide clearer info to the client
• Conform to a specific API implementation

[davidfowl]

I think this goes beyond the optionality feature. It's anytime the framework automagically returns a response (e.g. if TryParse fails).

[captainsafia]

I think this goes beyond the optionality feature. It's anytime the framework automagically returns a response (e.g. if TryParse fails).

True, true. The fact that both the TryParse and optionality checks both build on top of the CheckParams logic means that they both provide status codes with no messages to the user.

[DamianEdwards]

Folks can customize the message via a middleware, using a marker object in metadata or items to enable/disable per endpoint (inspired by this reply tweet)

[davidfowl]

What's nice about this is that we don't need to add anymore configuration or concepts. It's just middleware.

[poke]

It would still be good if there was some global way to affect this. If the validating behavior is there by default with non-nullable parameters, then there should also be some way to control this default behavior.

I could imagine some callback that can be registered via options somewhere which default value is just the current 400 response behavior?

[DamianEdwards]

We literally have no extensibility points like that today in Minimal APIs and have been very hesitant to do so for .NET 6. We want to let people use and see what the wider feedback is before we start committing to API and more layers of extensibility (complexity). One of the reasons MVC is so complex today is because so much is customizable. While powerful it makes it difficult to learn and limits what we can do regarding performance improvements.

If it can be done with middleware and other existing concepts that don't require new API in a reasonable way, we intend to leave it that way, for now.

[poke]

While powerful it makes it difficult to learn

If “learning” or discoverability is a goal of the new minimal API, then I don’t think it should automatically respond with a 400 if it wasn’t actually produced in user code. Because that really is undiscoverable magic from the framework.

Especially if it returns just a blank 400 without any details, then that really makes it very difficult to diagnose and learn about this too. I deal often enough with users that aren’t even aware of how to access their server logs, who mostly rely on the content of the HTTP responses for figuring out what’s wrong. If there’s now a blank response, then imo this will do more harm than good.

And if you decide to produce some content, e.g. using ProblemDetails, then there needs to be a way to reconfigure this since ProblemDetails, being a relatively new spec, is only one of many ways to encode errors. And you wouldn’t want to have the framework be limiting here, especially since the minimal API is mostly a “do whatever you want, manually” way.

It would probably better to just throw an exception then which people could catch in a custom middleware to do custom handling, or which would bubble up until some default thing handles it.

[davidfowl]

Maybe a decent tradeoff could be using a response header. That would:

• Put something in the response by default
• Allow users to customize the response with above approach

We'd also continue logging what happened.

[DamianEdwards]

@davidfowl by that you mean the framework would set a header by default? What would it be (name/value)?

[davidfowl]

@davidfowl by that you mean the framework would set a header by default? What would it be (name/value)?

Yea, maybe just the exception text.

[DamianEdwards]

So a custom header with the exception message? Which exceptions are we talking about as I assume it would be constrained to some specific scenarios?

[davidfowl]

Or the problem details message? It's basically a way to get the data into the response without hampering the ability to change the response. When we do the problem details middleware it'll take care of these transformations I hope