I am designing an application that interacts with a RESTful API.
When returning error messages like
Unable to sign up user
Should the error message be generated by the app? or by the API? I am looking for best practices.
At the very least, the REST api needs to return an error code (e.g. 123) and/or an error key (e.g. "cannotRegister") which the application can then pick up in order to display a related message. This also helps when you're dealing with an application that is available in multiple languages. The app can then pick the related message from the appropriate resource bundle (translation). The API doesn't need to know in what language the user is viewing the application.
I try to handle as many errors as possible by the API. In environments with multiple clients this helps to keep things consistent and easier to maintain.
When performing the error handling via the API the mere status code is defintely not enough. The approach I take here, is to provide an additional error response body that also provides a human readable message as well as a more detailed message for the developer and a link to further resources that provide some extra explanation. In JSON this could look something like this:
Example taken from stormpath.
The clients then use the human readable
To handle i18n we use the HTTP
Simply put an error page url in your configuration file (web.config if asp.net), that displays the error page in case if an error has occured.
Using the api? never heard of it, but if it is global enough to trigger a message on any error, then may be it is good enough..
Use the app's configuration to trigger a custome error. If you cant use your own code, but put it somewhere that responds to any request , no matter what type of request, otherwise you will have errors slipping by!