In Spring HATEOAS, you can return a VndError object that looks like this:
[
{
"logref" : "some request id",
"message" : "your request was incorrect."
}
]
The mime type specification mentions some optional and required fields, but does not talk about adding additional fields.
If I were to extend the vnd.error payload to look like this:
[
{
"logref" : "some request id",
"message" : "your request was incorrect.",
"additional" : {
"some" : "additional",
"payload" : "fields"
}
}
]
Is the format still valid according to the specification?
There's no mention of the equivalent of xsd:any (documented here). i.e. there doesn't appear to be a way to extend the schema. If it's just one client that you control then you could 'fork' the schema and add additional stuff the client will know exists. However, if any client can access it and is expecting a vnd.error, which is what it expects if it sees application/vnd.error+json and if it doesn't ignore unknown attributes in its parser it could fail to parse and not even get the error.
Plus if a client doesn't care about the error but wants a Retry-After header instead, then the request will contain stuff not required.
Can you create a new endpoint /logref/ perhaps? The client can send the vnd.error logRef and get more info and you can send whatever you need back in that as it won't be a vnd.error response.
Ultimately, logRef is for the server side. Any client would only be interested in displaying the message to its user and the logRef should they wish to follow up the error but I suspect a ThreadLocal error may not make any sense to a client. The content pointed to by logRef would only make sense to the server.
Indeed, exposing implementation details to a client via a ThreadLocal error could be a security concern. Internal server errors should be verbose enough for the server developers to fix the issue and being verbose relies on clients not seeing those errors, which could contain sensitive implementation details.