Decision Proposal 068 - Enhanced Error Handling

[JamesMBligh]

Currently a placeholder for a decision proposal on enhanced error codes for specific API error scenarios.

[kaveenr]

Hello all,

Crosspost from ConsumerDataStandardsAustralia/standards-maintenance#36

Upon looking at the OpenAPI Schema given for the CDS v1 API it shows that the current error model ResponseErrorList_errors only support a single error type.

It is for the 422 Unprocessable entity exceptions of the POST calls in the API, this is further justified with the description Must be one of the following: 0001 – Account not able to be found.

Any considerations for introducing different error codes for HTTP bad request, Internal Server Error, etc?
With this, we are able to give textual descriptions in case of a missing attribute bad request as an example.

If only a single type of code is allowed why not make the OpenAPI schema code attribute an enumeration?

In the case of a GET request to /banking/accounts/{accountId} with an invalid accountID can the same 0001 – Account not able to be found be used as a response?

Cheers,

[CDR-API-Stream]

Hi all, further to the feedback received so far on this issue, the DSB has received constructive input on explicit error handling from the Bendigo & Adelaide Bank.

Error Handling Scenarios - Bendigo & Adelaide Bank.April 2020.pdf

[CDR-API-Stream]

This placeholder has been subsumed by the ongoing error handling consultations and will now be closed.