See also:
Upstream standards take precedence
For all error response scenarios, if the error behaviour is described by the associated upstream normative standard, such as OAuth, then that standard takes precedence over the Consumer Data Standards (CDS).
Error Payloads
Where no error payload is specified in the CDS, the implementer is free to return a null payload, or include information in the payload as desired.
If the implementer chooses to supply a custom payload, it must follow the format specified in the CDS. For each unique code value, the title field must be consistent.
CDS enhanced error codes
Any requests that have accounts without consent should be responded to with 422 Unprocessable Entity error.
In some cases, error codes differ across APIs. For example, Get Transactions for Account has both 404 Unavailable Banking Account and 404 Invalid Banking Account. The error code used depends in part on the way the resource is requested.
Non-disclosure
Non-disclosure as a response to a bad request, such as due to a lack of consent, is not a refusal or rejection of service.
For sensitive scenarios like fraud or consumer vulnerability, the disclosure of information could lead to harm. It is up to the Data Holder (DH) to determine what data they provide in the error description. It is also up to the DH to determine the appropriate error code in these situations.
Avoid partial responses
The DSB recommends against partial responses. When responding to scenarios where a single source is unavailable in a bulk response, the DH should return a 500 Internal Server Error.
Metrics
Error API calls and rejected API calls should be included in metrics for all the reporting statistics for average response, Invocation metrics, Average TPS (Transactions Per Second), and Peak TPS.
Timeouts can be excluded from the AverageResponse times in Get Metrics calculations. However, they should still be counted as errors.
Latency that affects the quality of data may not be considered unavailability, but it would still be in breach of the data latency requirements in the NFR and should not be considered a successful outcome.
Revocation
ADR or DH arrangement revocation must occur synchronously with returning a 204 response to the caller.
Security
When critical errors are encountered during the Data Holder authorisation flow that cause the flow to break, it is acceptable to present a dialog box to the user stating that the authorisation cannot continue.
The Data Standards Body (DSB) recommends including the x-fapi-interaction-id where the client has provided an access token and is using Mutually Authenticated Transport Layer Security (MTLS).
Blocking Misbehaving Services
Data Holders may block third-party provider solutions, such as Content Delivery Network or cloud security services, if they are deemed to be misbehaving, for example by screen-scraping. The standards leave the Data Holder to determine their own response, as long as they operate within the rules and in conformance to the standards. See CDR resources, Rule 9.4 reporting.
Energy sector: AEMO NMI errors
If there are errors resulting from the NMIs provided to AEMO, then depending on the error, the retailer must either correct the issue and re-submit the request to AEMO or relay the error back to the Accredited Data Recipient (ADR).
Teapot
The HTTP 418 I'm a teapot client error response code indicates that the server refuses to brew coffee because it is, permanently, a teapot. A combined coffee/teapot that is temporarily out of coffee should instead return a 503 Service Unavailable. This error is a reference to Hyper Text Coffee Pot Control Protocol defined in April Fools' jokes in 1998 and 2014. If you receive a 418 error in response to your request, it may indicate that the service responding sent the wrong error code. On the other hand, the service may be a teapot. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418.
Subsections
Comments
0 comments
Please sign in to leave a comment.