Description
A common error interface to be used for responses from the back end. This will allow to gather errors during a request and provide them in a common response format.
Proposed solution
During a request, there might be several error possibilities due to business logic.
As an example, validating request data may raise several errors. Each provided field may have certain validation rules. All of them can be reported in a single response. Other examples are trying to retrieve an entity which does not exist, or not having the appropriate permissions.
Streamlining how errors are reported also provides benefits for the front end. When a request fails, it is easy to parse the response and show a common error element with the provided message. Right now, the messages are defined in the front end, which might not know what exactly went wrong. This can be frustrating for users as there is no explanation or which actions to take in order to fix an issue.
E.g.: When updating a DMP, there can be several validation issues. Simply showing The DMP could not be updated is not very helpful. Showing an explicit message like The project title can not be empty provides a clear description.
Additionally, there might not be any validation errors but simply warnings about certain issues. It could make sense to provide a message like No contact person has been specified. While it is not necessary to set a contact person, it is a good idea to specify it due to the impact it has on the export.
Description A common error interface to be used for responses from the back end. This will allow to gather errors during a request and provide them in a common response format.
Proposed solution During a request, there might be several error possibilities due to business logic.
As an example, validating request data may raise several errors. Each provided field may have certain validation rules. All of them can be reported in a single response. Other examples are trying to retrieve an entity which does not exist, or not having the appropriate permissions.
Streamlining how errors are reported also provides benefits for the front end. When a request fails, it is easy to parse the response and show a common error element with the provided message. Right now, the messages are defined in the front end, which might not know what exactly went wrong. This can be frustrating for users as there is no explanation or which actions to take in order to fix an issue.
E.g.: When updating a DMP, there can be several validation issues. Simply showing
The DMP could not be updatedis not very helpful. Showing an explicit message likeThe project title can not be emptyprovides a clear description.Additionally, there might not be any validation errors but simply warnings about certain issues. It could make sense to provide a message like
No contact person has been specified.While it is not necessary to set a contact person, it is a good idea to specify it due to the impact it has on the export.Alternative solution