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)

644

Correlationid is a unique identifier attached to a feasibility request that allows us a trace each transaction or event chain associated with a request.