Main issue is that the library currently does not support passing OpenAPI 2.0 request parameters and response headers.
In OpenAPI 2.0, request parameters, request body, response body and response headers can be described using a slight variation of JSON schema v4. For some reasons, the designers of the specification decided to use 3 different shapes for those JSON schemas depending on where it's used:
request body and response body are the closest to JSON schema v4.
in request parameters, JSON schemas keywords are merged in with other parameter properties instead of being namespaced under a schema property.
request parameters and response headers have fewer JSON schema keywords.
This is arguably confusing and that's probably why they corrected it in OpenAPI 3.0 where there is only one JSON schema definition.
However many users might still want to take a request parameter or a response header and extract the JSON schema from it. That seems like a very legitimate thing users might want to do, regardless of the OpenAPI 2.0 design decisions above.
It turns out supporting OpenAPI 2.0 request parameters and response headers might not require much work since the only changes are:
some keywords are not present (e.g. properties), which does not require any work.
some request parameters have extra properties (e.g. collectionFormat or in) which can just be removed. For required, it's a little trickier, as it would need to be skipped when it's the boolean value of a parameter object, but not when it's the JSON schema keyword (whose value is an array).
This is a continuation of #9
Main issue is that the library currently does not support passing OpenAPI 2.0 request parameters and response headers.
In OpenAPI 2.0, request parameters, request body, response body and response headers can be described using a slight variation of JSON schema v4. For some reasons, the designers of the specification decided to use 3 different shapes for those JSON schemas depending on where it's used:
schemaproperty.This is arguably confusing and that's probably why they corrected it in OpenAPI 3.0 where there is only one JSON schema definition.
However many users might still want to take a request parameter or a response header and extract the JSON schema from it. That seems like a very legitimate thing users might want to do, regardless of the OpenAPI 2.0 design decisions above.
It turns out supporting OpenAPI 2.0 request parameters and response headers might not require much work since the only changes are:
properties), which does not require any work.collectionFormatorin) which can just be removed. Forrequired, it's a little trickier, as it would need to be skipped when it's the boolean value of a parameter object, but not when it's the JSON schema keyword (whose value is an array).type: "file": see #20Note that I can submit a PR if you want.