[Question] Is there a way to properly emulate InvalidModelStateResponseFactory in minimal apis?

[michaeltg17]

Hi.

When trying to migrate some existing endpoints to minimal apis, I discovered that is not as easy as in controllers to change the behaviour of a binding error (and I wanted to return the same responses...).

In controllers you have the InvalidModelStateResponseFactory which you can use to modify the response to these invalid requests:

When trying to do the same in minimal apis, I have found two ways, filter or middleware.

With a filter you get the arguments but you don't know why the binding failed (required parameter not provided vs. not parsable) and the arguments have default values (like 0 but you passed a string)

With a middleware you can catch the exception but you only get a message like "Failed to bind parameter "long id" from "this has to be a long"."

So the question is, is there another way so I can return the same response as before when using controllers but using minimal apis?

Thanks.

[captainsafia]

@michaeltg17 Thanks for filing this issue!

Unfortunately not, there isn't a super great way to do this with minimal APIs at the moment. We've been tracking this in the backlog via #35501.

The referenced issue recommends a workaround using middleware (ref).

With a middleware you can catch the exception but you only get a message like "Failed to bind parameter "long id" from "this has to be a long"."

Is there additional information not in the exception message that you would like to have access to? Also, can you share an example of the ValidationProblemDetails that you are currently returning?

[michaeltg17]

Hi, thanks for the reply.

I'm doing this test request:

To controller endpoint:

To minimal api endpoint:

This is the response from the controller:

{
    "detail": "Please check the errors property for additional details.",
    "errors": {
        "": [
            "A non-empty request body is required."
        ],
        "date": [
            "The value 'b' is not valid."
        ],
        "id": [
            "The value 'a' is not valid."
        ],
        "request": [
            "The request field is required."
        ]
    },
    "instance": "/TestController/Post/a",
    "status": 400,
    "title": "ValidationException",
    "type": "https://tools.ietf.org/html/rfc9110#section-15.5.1"
}

The errors object in the response comes from the ModelState which is passed into the constructor of ValidationProblemDetails, so it builds that.

Wanted the same response in minimal api, but in the exception I only have this:

So I guess this is hard to recreate as it happens during the binding... and the exception doesn't contain all the errors or all the parameters with their current values so that you can build something similar. I'm not saying it should though.

In any case this was what I was trying to do, but I'll try to return a different response in case of minimal api if there is no other option.

Regarding the workaround (#35501 (comment)), I don't really understand how it could help.

Thanks!

[fl1k]

The fact it returns empty 400 bad request response is the icing on the cake :)) Debugger can't reach into the area where the response is set so you have to guess what is happening and why the request just skips over the exception handler that is supposed to catch this

[captainsafia]

The fact it returns empty 400 bad request response is the icing on the cake :)) Debugger can't reach into the area where the response is set so you have to guess what is happening and why the request just skips over the exception handler that is supposed to catch this

The default behavior will return an empty response in Production scenarios. The default behavior of throwing an exception is conditioned behind an environment check.

With regard to this issue in general, some of the recent work we're doing in the validation space will make it easier to access errors related to certain issues (required arguments that aren't passed).

We still don't have a robust solution for capturing other kinds of issues (failures that occur when trying to parse values) outside of a custom BindAsync implementation.