In backend code, when a REST endpoint method produces an exception, the endpoint should return a payload with an appropriate http error status, such as 500. It is also a good practice that the payload of the REST response should not include the exception itself because this can leak security information. Logging the exception is also good practice for later debugging.
What we would like to do is return a payload from the REST call that can be later correlated with the log entry. One way to do this would be to have a pattern like the following:
// next line would be nice, but doesn't work long timestampOfLogEntry = LOGGER.error("Unexpected error in REST call", exception); // return a REST payload with the timestamp - so we can lookup the error later return status(INTERNAL_SERVER_ERROR, new response("Unexpected error", timestampOfLogEntry))However, the LOGGER methods have 'void' return types, instead of returning a timestamp or anything that could be natively used to identify the log entry later.
One solution would be to capture our own timestamp and include it in the log, but that would be redundant with the timestamp the logger framework creates automatically. We could also create some sort of random number to include in both the log and the return payload, but that adds noise to the log.
This seems like a problem universal to all REST endpoint implementations, at least those using Java and common logging frameworks. Is there an common solution I've overlooked?