vertx-web
vertx-web copied to clipboard
vert-x3
Make Validation Handler Optional
Version
4.2.0 and future versions
Feature description
Please consider adding the validation handler as optional, perhaps adding an option at RouterBuilderOptions.setMountValidationHandler(boolean)
Context
During router creation on OpenApi3RouterBuilderImpl, instance of ValidationHandlerImpl is added to the handler chain and there is no option at the moment to avoid that.
This causes query params, headers including Cookies and specially the request body to be parsed, even if you don't want it, when for example content-type is 'application/json'.
Also, the reference to all these objects are held in memory during entire request lifecycle at RoutingContext -> data -> 'requestParameters' & 'parsedParameters' on ValidationHandlerImpl
Use cases
- Prevents duplicate parsing, when for example RequestContext.getBodyAsJson() is called at later stages.
- Improve performance by parsing when required and if required at later stages.
- Prevents duplicate memory holding on parsed objects at RoutingContext -> body and RoutingContext -> data -> "requestParameters" & "parsedParameters"
- Improve memory utilization & gc timing.
I would like to avoid adding it to the handler list by making it optional, see OpenAPI3RouterBuilderImpl.java#L273
yes but what would the router do if there is no validation ? it is not clear to me
The router would ignore the validation (no validation handler is set at all) the body would be parsed when required on router handlers by calling e.g. ctx.getBodyAsJson(). No validation against the model defined on the OpenAPI models would be applied, no validation error would be thrown in case of discrepancy between the specified OpenAPI model and the content. The user has to decide whether wants to validate against OpenAPI later on or not.
@lceni imho this sounds like an antipattern to me. I assume that users who want to use openapi are interested in a "strict" API contract, this means that the inputs are validated before they are given to user handlers, so users, don't have to address validation concerns in their handlers. Users would just write busines code.
Removing the validation, feels counterintuitive to me. If I really don't want to validate my incoming requests, why not just use a router directly? If the reason is just to have routes to match the openAPI document, I believe it would be easier to just load the json object and iterate the paths array and bind then to the router as a utility class.
As in many other projects we parse JSON input to Java classes using Jackson. During the parsing, we execute the validation. Therefore for all valid payloads, the validation is effectively executed twice.
Additionally, the request payload is parsed once as JSON by the Vert.x OpenAPI library and once as Java objects. The JSON is kept in memory for the whole duration of the request.
Having an option to turn off the body validation would prevent that. At the same time the Vert.x OpenAPI lib will execute the rest of the validations, which is exactly the same, when the payload is not JSON, UrlEncodedForm, or MiltiPartForm.
IMHO having the ability to turn off/deactivate the Validation Handler either partially (the body validation at least) or entirely brings value to the framework allowing more use cases to be fulfilled. Do you agree?
In our case Vertx's json validation is extremely slow for deeply nested JSON, to the point where our API grinds to a halt for some requests. With no option to disable vert'x built-in validation, we're forced to find a work-around which is not pretty.
We can't wait around for a fix to this difficult problem to arise in vertx-json-schema project or to develop one ourselves and get it approved. So providing a way to opt-out is always a better idea than forcing us into vertx built in json validation.
Similar to Iceni, we do our own validation too, so effectively validation happens twice.
