One real case we have is e.g. to show blacklisted words found in a string.

An error response in our rest environment looks like the following:

{
  "status" : 400,
  "message" : "Some data in the request body failed validation. Inspect the field errors for details.",
  "field_errors" : {
    "code": "BLACKLISTED_WORDS",
    "path" : ["presentation", "en", "title"],
    "message" : "The value or some words within a text or an array of values are blacklisted and can not be used."
  }
}

We generate this error response by mapping constraint violations (resolve the path nodes etc.) to this structured error response. In case of blacklisted words, it is essential for a consumer of our rest api to see which words of a string are actually under error.

Given the string "Some aaa text containing xxx words", where "aaa" and "xxx" are marked as blacklisted, the api should clearly inform the consumer of what exactly is wrong with the data provided. Such structured contextual constraint information should be understood by a rest client, so that a transformation of such data into a meaningful error to the user of the app is possible.

Today we abuse the message template to store a complex structured string to have the following addition in our error response:

...
  "field_errors" : {
    ...
    "payload" : {
      "blacklisted_words" : ["aaa", "xxx"]
    }
    ...
  }
...