Closed codyaray closed 4 years ago
@codyaray Thanks for the PR! It seems to lead to failed tests, though, which also affects https://github.com/ErikWittern/openapi-snippet/pull/35, as it builds on this one.
The issue seems to be that the example petstore_swagger.json actually defines multiple values for consumes
and produces
types, including application/json
and application/xml
. By picking the first type, in some cases application/xml
is selected, which leads to the payload being formatted as a string instead of a JSON object.
Maybe you could add to the PR so that, if multiple mime/content types are defined, it first tries to select application/json
and only selects the arbitrary first type defined if application/json does not exist?
You're right. But we actually decided to move away from application/vnd.json+api
so I'll just close this.
Obviously someone else is welcome to re-open and complete this if they need it. :)
@ErikWittern I need application/vnd.api+json
support to generate payload as well. Is this a quick fix ?
@kwent I am really not familiar with application/vnd.api+json
. If a requestBody
object has content
that uses application/vnd.api+json
as its media type, will the description of that data also be based on JSON schema? I.e., could it be that these checks should simply also consider application/vnd.api+json
?
We're building on https://jsonapi.org/ and specify the content type in our OpenAPI as
application/vnd.api+json
as required by this spec.This PR just updates it so that we can support JSON-based content-types with custom names, instead of just
application/json
(though that is the default still)