-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Query Parameter Transaction #176
Comments
Related and unanswered since February 22: #141 |
Commonwealth Bank posted this change request 02/04/2020, and related issue #141 was posted 22/02/2020. No responses were provided to either issue. Commonwealth Bank requested that this issue be included in maintenance iteration 3, but it was not included. We request this issue be labelled urgent and addressed for July. |
Hi @commbankoss currently the standards require text filtering to be managed through the use of the
Whilst a Data Holder may not support a given feature such as text filtering, it was intentional to avoid a hard error. This allows:
Continuing to return a 200 OK in situations like this but having a more expressive structure to identify which fields are unsupported may be practical. The DSB would welcome any other participants to provide their views. |
Given previous questions have been clarified why an error is not desired, it is still reasonable to expect that The following proposed changes to be made are:
3. Options for handling unsupported query parametersThe options proposed for feedback are:
|
As per #141 this addition was never documented nor has a decision proposal associated with it. This was raised ~5 months ago with no response from the DSB after more than 2 months and closed because I gave up waiting. On this basis @CDR-API-Stream Option D is to remove it as an undocumented change, accept that text filtering may or may not be supported (essentially consider it non-functional for 1.0.0) and formalise a proposal that considers things effectively. There are now live implementations in play so what support for In addition, Option E would be to establish an As for your proposed options: Option A: The parameter is poorly named and this approach precludes any ability to effectively use it to signal lack of support for other parameters in the future. This proposal only seems appropriate if the parameter name itself is changed to Option B: This is an option but is boolean in nature. There are foreseeable situations where certain parts of a query parameter (for instance, some of an enum but not others) are unsupported but the parameter itself is supported in some cases. Option C: This blows up the complexity of This issue was highlighted months ago with no response. The easiest solution is to drop it entirely, start fresh as to what the goals are and make a decision in the interim behaviour. |
Thank you for your responses @perlboy and @CDR-API-Stream. We support perlboy's proposed Option E, as it aligns closely to our original proposal. The main changes we see as necessary are:
We invite other ADRs to comment on their use of the |
Agreed with @perlboy and @commbankoss, HttpStatus code |
Based on what we've observed in market we do not believe any ADR is currently using any filter parameters in transactions, primarily because DH implementations are inconsistent for min/max-amount and start/end-date implementations. This makes this proposed change non-breaking. Given the cycle time on maintenance this change looks likely to take until February before approval resulting a resolution time in excess of one year from the original issue being raised. |
Hi @commbankoss As this change resolved an issue with missing schema detail in Get Transactions For Account, do you consider this issue can now be closed, or further consultation is required? I believe some of the original concerns may have been addressed by comments here and here. |
If there are no further comments on this issue it will be closed on 28 June 2024. |
Description
For the transactions endpoint, specifically Get Transactions for an Account, a data recipient who chooses not to support the “text” search field as a query parameter, are required to return a flag “isQueryParamUnsupported” in the response meta data object to indicate that the field is not supported.
The field name is not indicative of which field is not supported (i.e.) no reference to the text search field.
It’s not clear what’s is the purpose of returning this field with every response. It should suffice to include it in the API documentation.
Area Affected
Handling optionality of the “text” field in the Get Transactions for an Account query parameter if not supported by the data holder.
Change Proposed
In case the Data Holder choose not to support the “text” search query parameter for the transactions summary endpoint (Get Transactions for an Account), the data holder must:
Document the fact that the query parameter is not supported in the API documentation published on the Data Holder’s dev portal.
If the text field is provided by the data recipient whilst not supported by the data holder, the data holder will return an error indicating that the “text” parameter is not supported. This is in alignment with providing any other unsupported query parameter.
The text was updated successfully, but these errors were encountered: