TruBudget
TruBudget copied to clipboard
Consistent content of API responses
This issue is related to #940
Description 💡
The HTTP response bodies of API, excel-export, storage-service, email-service do not have a consistent format. This makes it very difficult to display human readable error messages in the frontend snackbar.
To resolve this issue, all HTTP error response bodies should have the same format that consists of:
- Version
- Error stack
- Human readable error message (that can directly displayed to the frontend). In the API, this could the last VError message. Returning a human readable error message is also a best practice, see https://www.baeldung.com/rest-api-error-handling-best-practices and https://nordicapis.com/best-practices-api-error-handling/
For example, the current error response from the API looks like this:
{
"apiVersion":"1.0",
"error":{
"code": 403,
"message":"global.disableUser failed: failed to disable user: user root is not authorized for global.disableUser"
}
}
This could be changed to:
{
"apiVersion":"1.0",
"error":{
"code": 403,
"stack":"global.disableUser failed: failed to disable user: user root is not authorized for global.disableUser",
"message":"user root is not authorized for global.disableUser"
}
}
Goal is to have a global TruBudget Convention/Standard that defines how HTTP Responses should look like in order to display user relevant information in the frontend (Message property in response).
Relates to/ Solves #111
TODOs
- Review best Practices and create a central concept for Http responses in TruBudget
- Make sure Errors are logged as well as passed in the HTTP Response in every Endpoint
This issue has been automatically marked as stale because it has not had activity for 30 days. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had activity for 30 days. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed because of inactivity. You can re-open it if needed.
TODOs:
- Define Standard response body for error and oks
- Apply it to all services
For the error standard: stackTrace and message should be part of the standard, where message is a readable reason