Client-generation: Allow data validation on the client side (using minLength/maxLength)

[jfiala]

Currently the generated Java-clients perform required-validation automatically.
Do you think this makes sense for minLength/maxLength as well, to reject the request on the client side before sending to the server?

For Java the JSR-303 Bean Validation API could be used for this automatically.
For other languages maybe a JSON-schema validation could be used.

[wing328]

@jfiala yes, it's definitely something we want to leverage and I'm sure the community would appreciate your contribution on that.

Let me know if you need help.

Ref: https://github.com/swagger-api/swagger-codegen/blob/master/CONTRIBUTING.md

[wing328]

@jfiala may I know if you need help adding the JSR-303 Bean validation to the Java API client?

[jfiala]

@wing328 thank you, maybe we can sketch some of the main features:

• I think it should be configurable so users can turn it on/off if they don't want bean validation annotations in the client code
• Bean Validation would make sense for every Java generator, but with the current layout (everything in mustache templates) it means I'd have to add it to all templates, do you have any better ideas?
• More general: Currently there are generators for server/client code kept separately, but shouldn't they be provided together (as for CXF for example where one can switch to generate impl/interface) as the model is always shared between server/client and should be the same to the bigger extent?

[jfiala]

Currently we could add support for the following annotations:
http://docs.oracle.com/javaee/6/tutorial/doc/gircz.html

• @NotNull (required=true)
• @null (required=false)
• @SiZe (minLength/maxLength)
• @min (min)
• @max (min)
• @pattern (pattern)
• @DecimalMin (min for BigDecimal)
• @DecimalMax (max for BigDecimal)

Pls let me know if other annotations make sense in the scope of Swagger?

[wing328]

@jfiala I think your list covers what we've already covered for other generators (e.g. PHP, Ruby).

Bean Validation would make sense for every Java generator, but with the current layout (everything in mustache templates) it means I'd have to add it to all templates, do you have any better ideas?

Please add it to Java okhttp-gson API client to begin with and we'll do the same for other Java client/server generator one by one.

[cbornet]

Duplicate #2412 ?
See also #2663.

Also Java client pojo.mustache only differ by a few annotations between gson and jackson (@serialized vs @JsonProperty) so it should be very easy to mutualize them under a parent mustache with a "gson" tag.

[jfiala]

@wing328: I added the first annotations to the Java language, see jfiala@08b3b53

Supported beanvalidation annotations (http://docs.oracle.com/javaee/6/tutorial/doc/gircz.html):

• Null, NotNull
• Pattern, Size for string
• Min/Max for integer

Questions:

• Should we add a flag to the CodegenParameter to switch Bean validation API support on/off?
• Min/Max need an integer value, but {{minimum}}/{{maximum}} inserts a double. Should we add minimumLong/maximumLong to CodegenParameter to insert a long value?
• I added Bean validation API 1.1.0.Final to the pom.mustache, or should I use ${validation-api-version}?
• to also support BigDecimal DecimalMin/DecimalMax I need to check if the type is "number", should we add CodegenParameter.isNumber?
• As Pattern/Size only applies to strings, I'd need CodegenParameter.isString to check.
• As Min/Max only applies to integers, I'd need CodegenParameter.isInteger to check.

[cbornet]

Note : "required=false" is not equivalent to @null