You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There should be an option to skip response validation. The response from the actual API is the canonical response.
So when the API gives one, we should be able to receive it. If the response from the API does not validate, there should be an option not to be strict and error, but instead try "best effort".
References
For example, lets say an API says a field is required in the response, but its only available in the response under certain conditions.
I've worked with an API that behaved like this:
The Spec says the "users" field is required in the response
If the API has users, it returns a "users" property filled out with the users it found
However, if there are no users, it returns an empty object:
=> | GET /users
<= | {}
The code generated by ogen check to see if the response contains the "users" property and fails in the second scenario; when in reality I don't actually care. I have no control over the OpenAPI Spec of the API in question, so unless it is fixed upstream I would have to make some manual edits to the spec before generation in order to make it optional and prevent this from erroring out.
The text was updated successfully, but these errors were encountered:
Description
There should be an option to skip response validation. The response from the actual API is the canonical response.
So when the API gives one, we should be able to receive it. If the response from the API does not validate, there should be an option not to be strict and error, but instead try "best effort".
References
For example, lets say an API says a field is required in the response, but its only available in the response under certain conditions.
I've worked with an API that behaved like this:
The code generated by ogen check to see if the response contains the
"users"
property and fails in the second scenario; when in reality I don't actually care. I have no control over the OpenAPI Spec of the API in question, so unless it is fixed upstream I would have to make some manual edits to the spec before generation in order to make it optional and prevent this from erroring out.The text was updated successfully, but these errors were encountered: