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

Best way to specify we only want to validate the response? #149

Closed
harrisj opened this issue Mar 17, 2017 · 1 comment
Closed

Best way to specify we only want to validate the response? #149

harrisj opened this issue Mar 17, 2017 · 1 comment

Comments

@harrisj
Copy link
Contributor

harrisj commented Mar 17, 2017

Things have been working great for 200 responses from my API, but I am interested in using flex to validate API responses for invalid inputs like when a query parameter is not within an enum. The issue I have right now is that the validator rejects the request as being malformed (which it is by design) before it verifies the response. I'd like to file a PR to allow me to just validate the response, but it seems like there are a few options I can explore:

  1. Call validate_response directly, but this seems like I am violating the abstraction, and I would also need to normalize the response before I pass it in. But this would work now without any changes, I think
  2. Refactor the validate_api_call method to call a validate_api_response method that is a wrapper around the normalize_response and validate_response methods that I could just call from methods where I want to validate the response.
  3. Add a parameter like only= to validate_api_call that takes either response or request as arguments and uses that for calling the validation.

I was leaning towards the third option at first, but I realized that people might think they don't have to pass in a request object when only=response but we still need that request object to know the HTTP method we are validating the response for. So I am kinda leaning towards the second option since it makes that more explicit. What do you think?

@ahartoto
Copy link
Contributor

ahartoto commented Mar 21, 2017

I vote for option 2. Let me elaborate a little more.

Option 2 will allow us to keep it backward compatible, and add a new functionality. Adding a new parameter can cause confusion when one changes a version from another.

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

2 participants