Skip to content

Check configuration correctness on the client library level #481

Open
Open
Check configuration correctness on the client library level#481

Description

@MariaMozgunova
MariaMozgunova
opened on Aug 4, 2023

I noticed that if I provide Products("income_verification") to LinkTokenCreateRequest, but do not specify appropriate parameters for the LinkTokenCreateRequest, like below:

user_token=<user_token>,
income_verification=LinkTokenCreateRequestIncomeVerification(
    income_source_types=[IncomeVerificationSourceType("bank")],
    bank_income=LinkTokenCreateRequestIncomeVerificationBankIncome(
        days_requested=<days_requested>
    ),
),

I will get the invalid request error.

But this error is returned from Plaid API. Why not do this check at the level of the plaid-python library as well?

The possible analogy coming to my mind is the validation of the fields on the websites. Validations usually take place both on the front-end and back-end. Front-end needs to validate the data in the input field because it will be faster than sending invalid data to the back-end. In the case of the plaid-client library, it acts as the front-end. If we know that some additional attributes should be set when Products("income_verification") is listed in the products list, why not do the check?

Activity

  1. phoenixy1 commented on Aug 4, 2023

    @phoenixy1
    phoenixy1
    on Aug 4, 2023
    Contributor

    So, there is a design tradeoff in the SDK between accepting data that might be invalid and providing flexibility -- we do have a design goal of not requiring people to upgrade the SDK unnecessarily and we tend to err on the side of being more flexible in order to accommodate additive changes in the API.

    However, this design goal applies really to handling responses, since those can change without developer action, whereas requests will only change if the developer takes a specific action to do so. I suspect the current behavior, in which we are not validating enums in requests, is probably an unintentional side-effect of changes we made to allow flexibility for additive changes to enums in response handling.

    I'm going to leave this open for the team to take a look at, because it's valid feedback on the SDK design. However, I'm not sure what it would take to fix it without changing our behavior for enum flexibility in responses (if if that's even possible).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions