@CompileStatic class ResponseMetaDataViolationPart extends Object
Part of the response metadata that describes violation when request processing ends up in some error.
For successful responses, it should not be rendered. An example of metadata containing violation part rendered for domain failure can be seen in the following example:
{
"metaData": {
"general": {
"severity": "warning",
"locale": "en_GB",
"timestamp": "2020-04-30T16:03:48.795816Z"
},
"violation": {
"code": "400",
"message": "Destination location cannot accept cargo from specified origin location.",
"type": "domain"
}
},
"payload": {}
}
| Type | Name and description |
|---|---|
String |
codeThe primary code describing the main category of the violation or error. |
String |
logUuidViolation identifying UUID contained in the message of logged exception. |
String |
messageA localized human-readable message describing the code property. |
String |
typeType of violation as a lowercase string corresponding to the values of ViolationType enum. |
ResponseMetaDataValidationReportPart |
validationReportViolation part containing detailed information about validation failures. |
| Constructor and description |
|---|
ResponseMetaDataViolationPart() |
The primary code describing the main category of the violation or error.
In general, it does not have to be designed to be human-readable, but rather it should be in the form of some violation/error identifier. For example, the categorization of HTTP response statuses (200, 400, 404, 500, etc.), or database error code categorizations, are good examples of the kind of information that should go in here.Violation identifying UUID contained in the message of logged exception.
We cannot recover from some violations. A typical example is aNullPointerException raised during the execution of server side code. The usual method for handling such exceptions is
to log them on the server and report them as generic exceptions to the client (without passing the stack trace). However, to enable the client to report the issue, there is a need to reference
the concrete exception somehow. This logUuid is that kind of reference. The client can use it while reporting the problem, and maintainers can then correlate it with the stack trace in
the log.
Property logUuid should occur in the response only if the exception stack trace is written in the log on the server-side. This should always happen for violations with error
severity. For other severities, it may or may not occur, and usually will not.
A localized human-readable message describing the code property.
Type of violation as a lowercase string corresponding to the values of ViolationType enum.
This information may be valuable for the client when deciding how to handle the violation. Violations of different types may add additional data in the violation part.Violation part containing detailed information about validation failures.
This part is rendered only when violation failure occurs. It is not rendered for any other failure type (domain, other or unknown).Groovy Documentation