Skip to content
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

All invalid api calls should always show feedback when possible #1399

Open
chrisjsimpson opened this issue Aug 21, 2019 · 0 comments
Open

All invalid api calls should always show feedback when possible #1399

chrisjsimpson opened this issue Aug 21, 2019 · 0 comments

Comments

@chrisjsimpson
Copy link
Contributor

chrisjsimpson commented Aug 21, 2019

Scenario

Developer using api submits a post request to /obp/v3.1.0/banks/BANK_ID/customers with an invalid value for kyc_status

Expected response:

When possible, the api response must inform the api user which field is invalid.

Actual response:

{"code":400,"message":"OBP-10001: Incorrect json format. The Json body should be the PostCustomerJsonV310 "}

Motivation

Developers should be able to troubleshoot api responses themselves, provided there is enough error feedback based on the structure of the data they send.

The actual repose is not helpful. Out of 22 possible data-points for this api call, the developer has no clue which properties are invalid.

Proposed solution:

use display_internal_errors or provide api validation only errors

When we enable the props setting display_internal_errors=True
Then the error message is more useful, for example:

{"code":400,"message":"OBP-10001: Incorrect json format. The Json body should be the PostCustomerJsonV310 <- No usable value for kyc_status\nDo not know how to convert JString(TRUE) into boolean"}
Right away , as an API user, it is possible to see the error is with the kyc_status property. The developer can now easily focus on correcting the data they are sending.

There is concern @hongwei1 that display_internal_errors is too broad for this , as it may show internal errors which are sensitive. Therefore maybe a more granular setting is needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant