1. Atlassian Avatar Atlassian
  2. Tooling and Automation
  3. swagger-request-validator
  4. Issues

support Swagger 2.0 basic format validators

Issue #36 resolved
József Börcsök created an issue

JSON Schema Draft 4 (see Previous Versions section at https://github.com/json-schema-org/json-schema-spec) doesn't support all Swagger 2.0 format attributes but only the following ones: date-time, email, hostname, ipv4, ipv6, uri, uri-template, uri-reference and json-pointer.

Swagger request validator should validate the following formats too:

  • string/date
  • integer/int32
  • integer/int64
  • number/float
  • number/double

Comments (12)

  3. Sven Döring

    I don't think the swagger-request-validator is the right place. It should be part of the Swagger Core itself. In https://github.com/swagger-api/swagger-core/blob/master/modules/swagger-models/src/main/java/io/swagger/models/properties/PropertyBuilder.java there is the possibility to define further, more specific Model definition which will then be used for validation in the swagger-request-validator.

    For example the int64 would be a regular long with a defined minimum and maximum - if not otherwise restricted in the Swagger schema.

    ps. the error description for the overflows might be misleading. The number “3.1415“ can not be parsed to int32, but it is not overflowing.

  4. József Börcsök reporter

    Format property is already exists and supported by both JSON Schema and Swagger specs, I think validation should follow standards. A similar solution was suggested by embedded JSON schema validator project for date format: https://github.com/daveclayton/json-schema-validator/issues/103 Simple custom constraints should applied by specific properties (minimum, maximum, minLength, maxLength, ...) as you mentioned above instead of custom format extensions. Current validation rules are inconsistent becase some of the Swagger 2.0 spec formats are validated correctly (i.e. date-time format and email inherited from JSON Schema Draft 4) but others are skipped (i.e. date).

    (validators are fixed, update is pushed to git feature branch)

  5. James Navin

    It looks like a reasonable approach. Parameter validation will already support these, but I agree that the JSON schema validation should support them also.

    I haven't looked into it in too much detail, but am I correct in assuming that if e.g. a String value is provided where an e.g. Number/Float is expected we will get the "incorrect type" validation already? From my understanding this change is just about further validating the format associated with the type.

    Could you please add unit tests that demonstrate correct behavior?

  6. József Börcsök reporter

    I will check invalid numeric type validation and remove unnecessary codes if those are already implemented. I will commit my changes (including new tests) to feature branch in a few days and inform you.

  7. József Börcsök reporter

    Format validators are updated and extendable unit tests are created too. A new schema factory method is added to SwaggerV20Library to so report provider log levels can be defined by caller component (i.e. overflow warnings are hidden by default). Main Swagger 2.0 formats are validated by JSON schema: int32, int64, float, double, byte (base64), date and date-time. (binary and password formats are ignored)

  8. James Navin

    Thanks Jozsef! I'll try to get a chance to look at it this week.

    (Im also chasing up why you can't create a PR - it will make the review process significantly easier if we can resolve that).

  9. James Navin

    I followed up with the Bitbucket team; they can't see any reason why you wouldn't be able to create a PR (all the project config looks fine).

    Can you confirm that creating a PR from the "Pull requests" page still doesn't work for you? If you see any error messages etc. let me know and I'll pass them on.

  13. Log in to comment
Assignee
–
Type
proposal
Priority
major
Status
resolved
Votes
0
Watchers
1