search

sylvainlaurent / swagger-validator-maven-plugin

A maven plugin that validates swagger files in yaml and json formats
Apache License 2.0
11 stars 6 forks source link

Unexpected validation error on consumes/produces with external references #22

Open giuliopulina opened 5 years ago

giuliopulina commented 5 years ago

Hi all,

while working on OAI/OpenAPI-Specification#21 I discovered a possible issue with consumes/produces validation. What I'm trying to do is:

1) using a valid OpenApi 2.0 spec file ('swagger-editor-external-ref-definition-imported.yml', that's the Uber API) 2) Importing some definitions from above file in another spec file ('swagger-doc-external-ref-definition.yml').

I'm getting an unexpected error during validation: [SemanticError at paths./test.get: 'produces' must be equal to 'produces: []', SemanticError at paths./test2.get: 'produces' must be equal to 'produces: []']

I'm afraid I need to change the 'imported' file to make this work, but I think it's not correct (and, often, in real life you can't really do that).

Furthermore, I came across this recent discussion about semantic validation in OpenAPI (https://github.com/OAI/oascomply/issues/54) and there's no mention about consumes/produces validation (except this one: "Parameters with type of file must have a consumes of multipart/form-data or application/x-www-form-urlencoded"). Is it possible that the validation that has been introduced is too strict and not conforming to the OpenAPI 2.0 spec?

@oyeli can you maybe help on this? You can find failing tests and test files in my branch: https://github.com/giuliopulina/swagger-validator-maven-plugin/tree/bugfix/Issue-21_external_ref_with_no_dot_not_working

kh0ma commented 5 years ago

I can help with it. Because unfortunately, @oyeli doesn't have enough time.

@giuliopulina I have two approaches on how to deal with it:

  1. Disable this validation at all.
  2. Implement "disabling" functionality to explicitly disable some validator from maven configuration.

What do you think about it?

giuliopulina commented 5 years ago

Hi @kh0ma, thanks for helping :) I thought about it, and I would go for solution 1 because the additional validation is breaking some functionalities that, in my opinion, should work without additional configuration. If you need this validation for your project (and you're not using external references, or you can adapt imported files) you can still implement it as a custom validator.

What do you think about it? I can manage to do the code change in my branch, but I would be glad if you can review the change once I create the pull request