Responding gracefully in the event of errors and exceptions

In a classic application development, where the caller of your method runs in the same process as your logic, it's obvious that when an error occurs, the code will either throw an exception or return an error code of some type.

In a Web API application, we strive to get the same semantic, only that the caller doesn't run in the same process, and therefore, the error response should be serialized on the wire. HTTP already provides the notion of status code, which allows you to communicate to the caller if the request was processed successfully or not. Unfortunately, in many cases, this is not enough, and the users of your API are unable to understand exactly what the problem is by only looking at a single generic status code. Instead, it's better to provide a standard error object with finer details.

Adding a correlation identifier to responses

Not all application errors will result in an error response — there are times when the application...