Check configuration correctness on the client library level

[MariaMozgunova]

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?

[phoenixy1]

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).