Clarification Request:getStatus()

[sona-dhillon]

Request For Clarification

We are seeking clarification on the requirements and DataHolder Obligations around the discovery/getStatus API
https://consumerdatastandardsaustralia.github.io/standards/#get-status

1.Is this required for the Product Reference Data release?What are the implementation timelines for this API?

2.What is the intended usage for this API? Is this a healthcheck service that will be accessed by external users (Data Recipients/ACCC) or is it intended to faciliate internal monitoring within the DataHolder domain or any other purpose?
(Why and when would a DR/ACCC use getStatus, would a client not rely on invoking the API endpoint that they are interested in and rely on HTTP response
codes to manage retries, etc)

3. when do we return a PARTIAL reponse and what do we provide in the explanation? How do we list unavailable APIs
   https://consumerdatastandardsaustralia.github.io/standards/#tocSresponsecommondiscoverystatus

4. Please provide us with some guidance regarding the usage scenarios for this api so we can design the api implementation to cater for these.

Thank you!

[bmangalaganesh]

@sona-dhillon

Assumption: I am assuming you are looking at a non Big4 bank here.

Here is my understanding in this space:

1. I don't believe this is required for the Product Reference data release (July 2020)

2. The purpose of the get-status API is described clearly - Obtain a health check status for the implementation

The ADRs can make use of this API and see what they want to do. The usage is at the discretion of the ADR. The DH is expected to provide a status view of its CDR APIs.

An example could be there is a partial unscheduled outage (PARTIAL_FAILURE scenario) for e.g Accounts APIs. The ADR may choose to not make any Accounts API calls during that window.

As you stated the ADR could have invoked an API and see it fail and be clueless and try again or they can make a call to status and observe an outage and reschedule their calls as they see fit.

This is very similar to the status pages that are provided by cloud vendors that describes the state of their various services.

3. PARTIAL_FAILURE is defined as one or more end points are unexpectedly unavailable

[CDR-API-Stream]

Hi @sona-dhillon, answers provided below.

Thanks @bmangalaganesh - that is a good summary.

# 1 Obligation dates
Data Holders must provide this service as part of their consumer data sharing obligation dates. The Get Status and Get Outages endpoints are not required prior to this date but a Data Holder may choose to publish them early.

# 2a Intended Usage
The intended usage is to allow data recipients / API clients to understand when part or all of a DH's CDR service is unavailable. This is important when an ADR is looking to collect data they are aware that calling a DH during a scheduled maintenance window will not succeed and they should try again after the scheduled maintenance has completed.

# 2b Purpose
Both Get Status and Get Outages are public APIs. As such it may not just be ADRs or the ACCC calling these endpoints. Similar to the PRD endpoints, this may be any public API client.

# 3 Partial vs Full outage
The purpose of this is to inform API clients when there is a complete outage of the DH's CDR service vs some aspects of the CDR service being unavailable such as a CDR API or the DH's authorisation server.

The standards do not require a DH to provide a list of the affected APIs in a partial outage - this may not always be practical and the outage may not relate to the APIs but other aspects of the CDR service. The explanation field provides Data Holders with a mechanism to provide detail regarding the extent of the outage. If listing of unavailable APIs is considered an important feature enhancement, it could be considered under a change request.

# 4 Use cases
The purpose is explained above. It allows API clients to ascertain the current status of the CDR service provided by a Data Holder and it ensures that API clients are aware of any scheduled (planned) maintenance as well as unscheduled outages.

[sona-dhillon]

Thank you!

[CDR-API-Stream]

Captured as part of this Knowledge Article: https://cdr-support.zendesk.com/hc/en-us/articles/900001656623