If a REST endpoint fails to execute successfully it returns a JSON object of the structure
{
"status": <http_status_code>,
"error": "<some_error_message>"
}to the client.
This way the client is able to get more information about the error (except for the status code, which is redundant with the HTTP status code). In order to be somewhat independent of the actual error message the application should provide unique, application specific, status codes which help to better identify the error programmatically.
As an example, the endpoint addTrackToQueue returns with a status code 400 if the requested track already exists in the given queue. Which is fine, but the client cannot distinguish such an AlreadyExists error from a SpotifyBadRequest error.
If a REST endpoint fails to execute successfully it returns a JSON object of the structure
to the client.
This way the client is able to get more information about the error (except for the
statuscode, which is redundant with the HTTP status code). In order to be somewhat independent of the actual error message the application should provide unique, application specific, status codes which help to better identify the error programmatically.As an example, the endpoint
addTrackToQueuereturns with a status code400if the requested track already exists in the given queue. Which is fine, but the client cannot distinguish such anAlreadyExistserror from aSpotifyBadRequesterror.