Critical errors, recoverable errors, and warnings are examples of very common API error types. Below is a look at the difference between the three most common major API error categories.
Critical Errors
A critical error may be a timeout, where the system does not get a response during the pre-set time allowance. When something times out, there is no information about why the error occurred. The programmer has no details about if the system is down, if there was a problem in how the request was created, or if there was an issue with how the programmer is using the API.
This is called a critical error because the system will not recover anytime soon and the programmer has very little information from the system to solve the error.
Another example of a critical error could be that the programmer does get a response but the error message broke down, such as a 500 error. This error basically says “something broke, we don’t know what it was, and there is no additional information to help fix it.”
More: Managing the Unhappy Path
Recoverable Errors
Recoverable errors can be item such as the programmer’s own system is not utilizing the API specifications correctly. The programmer may have not sent a required value, or the data was formatted incorrectly.
Additionally, it could be that the end-user did something wrong, such as entering an incorrect password or credit card number. With proper error messaging, the system can alert the end-user to their mistake and prompt them to complete the request with the correct information.
A good API will share within the error messaging what was done incorrectly so that the programmer can make the proper changes on their end.
Warnings
Warnings could be that a request to the API was processed successfully but there may have been something that was not ideal in during the process.
An example of a warning would be if a travel booking was successful, so the primary business feature was a completed, however the seat that was requested did not get reserved. A warning would occur that would not stop the booking but allows for system administers to fix the problem or gives the end-user the opportunity to try again via a different method.
