Can you please add the MyState Bank URL to the Comparitor Tool

[phililes]

Hi,

Can you please add the MyState Bank URL to the Product Comparitor Tool.

https://openbanking.api.mystate.com.au/public/cds-au/v1/banking

Thanks

[vadkor]

@phililes please confirm via email to cdr-data61@csiro.au your association with MyState Bank.

[vadkor]

Association of @phililes with MyState bank confirmed via email.

[vadkor]

The URL is https://openbanking.api.mystate.com.au/public/cds-au/v1 BTW.

[vadkor]

We are going to submit the PR with this change together with an update to the Comparator that will help it to deal with the problematic data received from a Data Holder, such as the data from MyState Bank.

[phililes]

Hi, can you please advise what you are referring to with the reference to PR? Is there an issue with data from MyState Bank being problematic?

[vadkor]

@phililes , a Pull Request (PR) is a peer-reviewed (PR) request to merge your changes into the repository. That's what would have been great if you've raised instead of this issue. Here is an example: https://github.com/ConsumerDataStandardsAustralia/banking-products-comparator/pull/44 At least you should have tried adding [and enabling] the URL to the Comparator "Banks" section (using the Add button at the bottom of the expanded section) - you would have seen that there was something wrong with the response processing. Not to worry, we are already on it. The PR will be raised most likely tomorrow. In regards to problematic data, I would say, yes, generally the problematic data is an issue to any application. We do try to make the Comparator tolerable to some data abnormalities, but the data from the MyState Bank endpoints prompted us to do some additional work. The problems we have found with the product data responses from MyState Bank:

• Incorrect pagination links. The listProducts endpoint returns a single-page response, but for some reason sets prev and next links to a value different from self. Not to mention that for the first page the prev link shouldn't be set at all, as next shouldn't be set for a single-page response. Currently this causes the data briefly appear to be loading by Comparator, but at the end the result appears to be empty.
• The listProducts response contains duplicate products - with the same productId and productCategory
• The x-v response header of the get product detail endpoint indicate version 1, but the result type is of at least V2 since it contains the cardArt array. The fact that it's empty doesn't make its present compliant.

The last issue was something that the Comparator was handling correctly already, but it's just something we've noticed. I'm sure @perlboy will be happy to point you to more issues.

[perlboy]

@vadkor according to @CDR-API-Stream: Compliance is an ACCC concern

What I am not understanding is why the Consumer Data Standards Australia Engineering team is now implementing work arounds for non compliant endpoints (as well as accepting them in the first place). Are Recipients expected to implement the same workarounds?

This seems like an issue for clarification to be raised within standards-maintenance.

[vadkor]

@perlboy, we are not implementing workarounds. We are making sure that our tools produce results and give the information to the users even if the data is not 100% compliant. Our goal is to help the developers of the APIs to get off the ground. It's not good enough if the application crashes or freezes when encounters a data abnormality. The application needs to be stable and give the user as much information about the error conditions as possible. That's what we are trying to achieve with the current work. The code change will include not only handling of the data errors, but also some extra logging that will help the users to diagnose their APIs. In regards to people submitting their endpoint URLs, we absolutely welcome that. The wider the community grows the better. Everybody, including the consumers, can only benefit from the awareness of the open APIs. People who submit their endpoints to the public will also have extra incentive of working harder on the found issues because everybody can see them. Yes, we are not enforcing the compliance - the enforcement role is of the ACCC. At the moment only the Big Four must be compliant, but they are all failing in the Comparator due to non-compliance with the CORS requirements.

[perlboy]

@vadkor The problem we have with this approach is that it creates a double jeopardy situation where a compliant recipient may make a request to a holder to rectify a clear issue with their implementation (which we have, with varying results) while the response is that the (only) government maintained and endorsed product data implementation implements enough workarounds to make essentially anything work.

Conversely, presenting "data errors" and adding "extra logging" is quickly approaching a conformance validation which, by the DSBs own admission, is not their responsibility. This seems like a cake and eat it too situation.

Specifically regarding CORS, this appears to be a lack of understanding of CORS from the Australian Government rather than non-compliance. As the Standards do not provide any underlying RFC for CORS compliance Holders are entirely compliant with what has been explicitly mandated.

In fact, the introduction of CORS was, at the time, against the strong recommendation of the engineering team for exactly the issues in this space that are being introduced coupled with the likely (and now demonstrable) performance degradation of enmasse client side parsing of large payloads.

[phililes]

@vadkor, the duplication issue has been resolved and the other outstanding issues will be resolved by a release planned for the 29th. Will a new PR be required after that release to validate the API response?

[vadkor]

@phililes, the PR (#47) has been merged and this issue was closed automatically as a result. No need to raise anything new - your URL is live. It's not enabled by default. Only the Big Four are enabled by default.