ModelState does not adhere to DataMember Name or DisplayName

[carl-thomas]

When posting JSON data

{
    "name": "Dave",
    "email_address": "dave@dave.com"
}

to a endpoint that accepts the relevant model...

[DataContract]
public class MyModel 
{
    [DataMember(Name = "name")]
    [Required]
    public string Name { get; set; }

    [DataMember(Name = "email_address")]
    [Required]
    [EmailAddress]
    public string EmailAddress { get; set; }
}

When this model gets validated, if the validation failed and you return BadRequest(ModelState) you get the response e.g.

{
    "Name": [
        "The Name field is required."
    ],
    "EmailAddress": [
        "The EmailAddress field is not a valid e-mail address."
    ]
}

The keys are the property names e.g. EmailAddress and not the original DataMember name email_address

The response should adhere to the DataMember attribute so that the response resembles the external keys the user sees.

[mkArtakMSFT]

Thanks for contacting us, @carl-thomas. We're closing this issue as the change would be a breaking change as well as there was no community interest in this ask all this time.

[jrpharis]

Just a note on this, using FluentValidation.WebApi v7.6.0, adding the DisplayNameAttribute to the property will accomplish validation errors listing the modified property name. I didn't test with the AspNet version, but perhaps that will work there now as well.

[ans-ashkan]

This is serious, we need a way to change this. maybe opt-in ?

[wijwoj]

DisplayNameAttribute makes no difference. How are we supposed to get the field display name. It seems insane there is no way to do this.

[carl-thomas]

I don’t think this should be closed on the basis of no community interest. It is a fundamental flaw that has been missed. How is my api meant to parse errors that are returned with a different key? We shouldn’t be adding other attributes or libraries to fix something that should not be broken. I understand it would be a breaking change but like someone else has already stated an opt-in in the startup would solve this. I now have to write my own parser of the ModelState to reflect and get the original key.

[DMDTT]

I humbled over this issue a year ago with webapi 2.1 in combination with FluentValidation

then I saw https://stackoverflow.com/questions/39527583/how-to-use-fluentvalidation-with-metadatatypeattribute

ValidatorOptions.DisplayNameResolver = (type, memberinfo, expression) => GetPropertyDisplayName(memberinfo);

this could be enhance in many ways