Product Reference Data obligations for non-major ADIs

[CDR-API-Stream]

Request For Clarification

Two questions were raised during the Data Holder Working Group call on the 23/04/2020.

1. Does a data holder have to create V1 for the period 1 July 2020 to 29 August 2020 or are they able to create only V2 from 1 July 2020 onwards?
2. Up until Aug 29th 2020, can we tell clients that the minmum supported version is V2 and not support V1?

Standards reference

Answer

There was ambiguity regarding whether ADIs that are required to provide product data from 1st July 2020 would need to support both Get Product Detail v1 and v2.

The expectation is that:

• If an ADI had previously made v1 available they should keep it around until August 29th.
• If an ADI is going live from 1st July 2020 for PRD, they do not have to implement v1. Instead, those ADIs can choose to support only v2.

Version supportability should be clearly communicated using the version header defined in Response Headers. For clients calling the PRD endpoints they can request their desired version using request headers (see Get Products).

Note, if the client requesting the PRD data is requesting a version that the ADI does not support (e.g. the client has specified x-v: 1; x-min-v: 1 but the ADI only supports x-v: 2) then the ADI should respond with an error. The error response should be descriptive enough to explain that the version is unsupported and what version(s) are supported.

Standards reference:

If all versions requested are not supported then the data holder should respond with a 406 Not Acceptable.

For reference in Enhanced Error Handling (119, 120, 121) to cover version supportability errors.

[perlboy]

As stated in ConsumerDataStandardsAustralia/standards#121 (comment) the wording of should means that a holder is under no specific obligation to respond to unsupported versions in a consistent way.

As this affects July deliverables I would suggest this is treated as a defect and the wording made more explicit.

[CDR-API-Stream]

Thanks @perlboy. This has been included as a fix for v1.3.1.

[CDR-API-Stream]

This issue has been fixed and it is being closed accordingly.