Standardise API payloads as per the CDS requirements

[CDR-Register-Stream]

The CDR Register API payloads currently do not conform to the letter as per the CDS payload conventions specification. The issue has been raised to track work to move the API definitions in this direction

This issue was initially raised as part of issue #69

[CDR-Register-Stream]

As per #128 we will need to ensure that the required fields array doesn't conflict with the actual specified fields. As part of updates to the swagger definitions, this maintenance task should be performed

[CDR-Register-Stream]

This issue is currently associated with Project 1.3 targeting completion by February/March 2021.

We are seeking feedback from the community on where this issue sits in terms of priority and the potential impact for deferring addressing this post February/March 2021.

Feedback has been requested in this and other forums and will be considered until 1st September 2020

[commbankoss]

Commonwealth Bank is supportive of having consistent calling conventions for APIs, aligning to the CDS requirements. The impact this might have would depend on the specific changes involved. We request changes be deferred beyond Feb/March 2021.

[perlboy]

@commbankoss If the end state of this is beyond March then it will likely need to be beyond July as that is the scheduled date of non-Big 4 and prep/build for changes will occur in the first half of 2021.

This issue was raised 6 months ago and represents alignment to the overall Standards. This alignment should have already occurred and been raised by participating parties in accordance with the statement:

ACCC will follow the versioning conventions outlined by the Data Standards Body.

Delaying this will result in build changes occurring on potentially 10x more holder environments.

[NationalAustraliaBank]

NAB supports the uplift of API’s to follow the CDS payload conventions on the basis it is done as a new version of the API. We would expect that participants are provided sufficient time to implement the new versions of these API’s following an agreed version "sunset" approach (eg. similar to the obsolescence of Get Products V1 - introduction of V2 / V3).

[WestpacOpenBanking]

Currently our implementation is aligned with the current register specifications. In particular, build effort would be required for us to support this proposed change, including work to:

• Provide the x-v header with requests to the registry
• Support pagination across endpoints
• Support altered names of fields to align with naming conventions

For this reason we recommend that changes are aligned with a post-March register release.

[CDR-Register-Stream]

We are extending the request for feedback until 6th September to give collaborators greater opportunity to contribute

[CDR-Register-Stream]

Attached is a draft version of the swagger changes to accommodate the new payload conventions.

Standardised API Payload Swagger - DRAFT.yaml.txt

Note the key piece of work is the introduction of the data, links and meta payloads to standardise the structure of the responses.

Pagination is not defined in the public APIs as little value is seen in adding this functionality and increases the complexity of cache updates. As these APIs are intended to be machine to machine and compress well, we don't anticipate the payload sizes will to become unwieldy.

We welcome any feedback on this approach.

[CDR-Register-Stream]

The ACCC is keen to adopt these changes however the change management risk of delivering this as a separate piece of work is deemed unacceptable. Therefore, these changes will not be resolved as part of Design Maintenance Iteration #1.

We anticipate future work will require structural changes to accommodate sector agnostic APIs and therefore plan to group all structural changes together rather than fragmenting delivery of these changes

This issue will be left open to track and re-examined when significant changes to the APIs are required.