Error Handling
If something unexpected happens...
The HTTP response status codes are separated into five classes (or categories). The first digit of the status code defines the class of response. The last two digits do not have any class or categorization role. There are five values for the first digit:
• 1xx (Informational): The request was received, continuing process
• 2xx (Successful): The request was successfully received, understood, and accepted
• 3xx (Redirection): Further action needs to be taken in order to complete the request
• 4xx (Client Error): The request contains bad syntax or cannot be fulfilled
• 5xx (Server Error): The server failed to fulfill an apparently valid request
RFC2616 defines the codes: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
In general, there are three outcomes status in the interaction between an app and an API:
• Everything worked - success
• The application did something wrong – client error
• The API did something wrong – server error
Extensively we use the following three codes:
• 200 - OK
• 400 - Bad Request
• 500 - Internal Server Error
Additional codes used are:
• 201 - Created
• 304 - Not Modified
• 404 – Not Found
• 401 - Unauthorized
• 403 - Forbidden
For all 4xx or 5xx responses we use the Problem Detail standard (known as RFC7808 https://tools.ietf.org/html/rfc7807)
Correlationid is a unique identifier attached to a feasibility request that allows us a trace each transaction or event chain associated with a request.
Updated over 4 years ago