You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When documenting the "GET /doc/openapi.yaml" operation in OpenAPI, as in [doc-refdata], max compatibility with tooling is achieved when specifying the payload as binary:
Non-binary payload type: object has undefined behavior for YAML content-type. Binary format is also the only one allowed currently by the validator.
Can we document this payload format in the guide and add it to openapi-common? I often see problems with it in OpenAPIs (wrong media type or other schema).
Also, we could modify the [doc-refdata] rule to prefer publishing as YAML (SHOULD) over JSON (OPTIONAL), conform to [oas-yaml].
The text was updated successfully, but these errors were encountered:
Good question. We're currently doing this, as fat yaml, because otherwise the API Gateway blocks the request.
For documentation purpose, its self-referential so leads to chicken-or-egg problem. Maybe useful when client developers have another, possibly different, version of the OpenAPI document and want to check the current version on the server.
However, in case of secured APIs, they're probably missing an access token to retrieve it...
When documenting the "GET /doc/openapi.yaml" operation in OpenAPI, as in [doc-refdata], max compatibility with tooling is achieved when specifying the payload as binary:
Non-binary payload
type: object
has undefined behavior for YAML content-type. Binary format is also the only one allowed currently by the validator.Can we document this payload format in the guide and add it to openapi-common? I often see problems with it in OpenAPIs (wrong media type or other schema).
Also, we could modify the [doc-refdata] rule to prefer publishing as YAML (SHOULD) over JSON (OPTIONAL), conform to [oas-yaml].
The text was updated successfully, but these errors were encountered: