Bad request / validation errors by the framework should state field names according to RFC 9457

KillerBoogie commented 2 weeks ago

Is there an existing issue for this?

[X] I have searched the existing issues

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

When a MVC or minimal API request is missing required fields the returned Problem Detail is just a generic error, e.g.:

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.1",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "errors": {
    "$": [
      "The input was not valid."
    ],
    "request": [
      "The request field is required."
    ]
  },
  "traceId": "00-03b1705be061cd08d86ed334c2f45eba-9e23a09ceaa7eb18-00"
}

Despite that multiple fields have been missing in this request the message only says that 'request field' is required. There is no information what fields are missing. Additionally, the errors elements don't follow RFC 9457 recommendation to use details and pointer members.

Describe the solution you'd like

The framework should return for example:

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.1",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "errors": {
    "detail": "The field is required.",
    "pointer": "#/name"
    },
    {
    "detail": "The field is required.",
    "pointer": "#/address/street"
   },
  "traceId": "00-03b1705be061cd08d86ed334c2f45eba-9e23a09ceaa7eb18-00"
}

Additional context

No response

captainsafia commented 2 weeks ago

@KillerBoogie Thanks for filling this issue!

From my understanding of the problem details specification, the error field is an extension field and it is up to the implementation to dictate what the contents should be.

On possibility is using JSON pointers to identify the particular fields associated with each issue, things get interesting with baking this as default behavior in the framework because:

Until the recent introduction of JSON Schema support in .NET 9, we don't have robust mechanisms in the platform for generating JSON pointers out of fields.
We'd have to reason how these pointers will work for non-JSON payloads. I believe there is still a story in the JSON pointer spec for this but am not familiar with it.

It should be visible for 3rd-parties to implement this behavior by extending the ProblemDetails infrastructure in ASP.NET Core. If you're interested in doing this, I can share some more details as to how it might be achieved. Otherwise, I don't think think its high priority to change the current behavior of error handling at the time.

KillerBoogie commented 3 days ago

From my understanding of the problem details specification, the error field is an extension field and it is up to the implementation to dictate what the contents should be.

That is correct.

On possibility is using JSON pointers to identify the particular fields associated with each issue, things get interesting with baking this as default behavior in the framework because:

The current error message is non descriptive. Neither human nor machine can understand what the exact problem is. There is no detailed information, because the problematic fields are not stated. There is no need to use JSON pointers they are just a good option and standard to describe the problematic field(s) for a nested JSON structure. You can use anything that is descriptive.

It should be visible for 3rd-parties to implement this behavior by extending the ProblemDetails infrastructure in ASP.NET Core. If you're interested in doing this, I can share some more details as to how it might be achieved. Otherwise, I don't think think its high priority to change the current behavior of error handling at the time.

In general, I'm interested in that information, but I'm disappointed by.NET WEB API again. How can such a bad error message as stated in my example be approved by product quality management?

captainsafia commented 3 days ago

I'd recommend checking out the model validation docs for information on what customizations are available. The error message you see here is the default one but there are ways to customize it to your liking that are documented in this page.

dotnet / aspnetcore