-
-
Notifications
You must be signed in to change notification settings - Fork 810
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
Clarify absence of OapiResponseValidator
and make middleware options more specific
#1038
Comments
Hi Anton. I've been looking at this too as I'm also interested in response validation. It looks as if the options struct is imported from a different package It looks like it would be useful to either:
|
i'm going to look at creating this middleware, will update here when i have a PR ready |
i've got the bones of this for gin (which is the http router we use) but it could easily be repurposed to different implementations oapi-codegen/gin-middleware#13 |
Thanks for the work on this! What use cases do you have for this? Would be interested to know just so I can gauge how it's going to be used. Ie should it be configurable that it actually stops the malformed response going to the caller or should it just ie log? For testing purposes I wrote https://pkg.go.dev/openapi.tanna.dev/go/validator which may be helpful but if you want the full app integrated then the proposed solution looks good. |
Essentially this is for use in conjunction with the Having it be configurable in that sense is not something I'd considered, but would be desirable. For some use cases, having such a strict all or nothing approach to response validation is overkill, as the consumer might not be interested in the areas where the schema is violated. So I can get behind providing the option of hooking in with a log-only implementation. Testing schema compliance before releases is a sensible thing to do in its own right, and ultimately just as (if not more) important as having this type of middleware running in the deployed API. That tool looks like a really good approach, I'll definitely check it out. |
I realise actually that it readily configurable using the To maintain the consistency with the request middleware, I'd say this is the best approach for this. |
Hello!
OapiRequestValidatorWithOptions
has ambiguous API. Not all fields fromopenapi3filter.Options
are used:My bad, but I was sure that the oapi-codegen could validate the response.
And was surprised to find that there is no use of the
openapi3filter.ValidateResponse
.The text was updated successfully, but these errors were encountered: