To eliminate confusion for API users when an error occurs, we should handle errors gracefully and return HTTP response codes that indicate what kind of error occurred. This gives maintainers of the API enough information to understand the problem that’s occurred. We don’t want errors to bring down our system, so we can leave them unhandled, which means that the API consumer has to handle them.

Common error HTTP status codes include:

400 Bad Request – This means that client-side input fails validation.

401 Unauthorized – This means the user isn’t not authorized to access a resource. It usually returns when the user isn’t authenticated.

403 Forbidden – This means the user is authenticated, but it’s not allowed to access a resource.

404 Not Found – This indicates that a resource is not found.

500 Internal server error – This is a generic server error. It probably shouldn’t be thrown explicitly.

502 Bad Gateway – This indicates an invalid response from an upstream server.

503 Service Unavailable – This indicates that something unexpected happened on server side (It can be anything like server overload, some parts of the system failed, etc.).

We should be throwing errors that correspond to the problem that our app has encountered. For example, if we want to reject the data from the request payload, then we should return a 400 response as follows in an Express API: 

https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/