v2 spec is invalid about openapi HOT 6 CLOSED

I just wanted to say for now: thank you for the detailed report here.

Unfortunately, I'm not sure when I can get around to fixing most of this, but it's good to have this level of detail of information available.

from openapi.

No doubt that this would be a large effort if you were to try and and attack this by fixing code and Swagger annotations, but it isn't such a big deal if you clean it up in a post-processor like I did. I would be happy to share my preprocessSwagger method in the swagger-codegen plugin I created. It cleans everything up enough so that it passes validation and can be used with swagger-codegen. It is written in Java, of course, but it would be rather easy to translate it to the Ruby equivalent. Just tack it on to the end of your build process and you should be good to go.

from openapi.

@mutsys Thanks a lot for the offer!

I think you're right in that applying a post processor would be the easiest fix for our problems, but I kind of feel like we'd just be papering over real problems and adding another layer of complexity overhead to our stack. Pretty much everything here is representative of an actual issue (e.g., non-unique operation IDs), and by far the cleanest fix is one that happens right at the root where we generate the original spec.

from openapi.

How about this one: all input parameters are defined as body parameters while Stripe wants x-www-form-urlencoded which is defined like this:
` parameters:

    - in: formData

      name: name

      type: string

      description: A person's name.

    - in: formData

      name: fav_number

      type: number

      description: A person's favorite number.

`

from openapi.

@sanderPostma I'm sorry to say that one is certainly not going to be changed.

The formData specification is simply not adequately expressive enough for our purposes, which often include more complex data structures. OpenAPI 3.0 does a better job of addressing this, so I'd recommend moving to that for a system that's a little more adherent to recommended practices.

I'm also not even sure this is necessarily invalid. Reading describing request body, it's suggested that formData is usually used, but the language doesn't imply that that use is necessarily exclusive.

from openapi.

I apologize for the extremely delayed response.

We've since moved to OpenAPI v3 and improved the quality of API descriptions. If you encounter problems when using the new OpenAPI 3 spec please file a new issue.

from openapi.