fix, test and document openapi named examples #639
Conversation
opqdonut
force-pushed
the
fix-openapi-examples
branch
from
39b69e1 to
38547e4
Compare
opqdonut
changed the title
|
|
||
| ["/pizza" | ||
| {:get {:summary "Fetch a pizza | Multiple content-types, multiple examples" | ||
| :content-types ["application/json" "application/edn"] |
There was a problem hiding this comment.
wait what? when and why did we add the :content-types? isn't the map keys in :content the correct source of supported types? I feel this is duplicate info which can can cause hard to track errors, e.g. defining inputs for multiple content-types under :content and not setting this value will cause only "application/json" to be supported (the default from code).
There was a problem hiding this comment.
e.g. this is not part of OpenAPI Spec.
There was a problem hiding this comment.
:content-types is there as the analogue of :swagger {:produces [...]}. It's not directly copied to the openapi spec, but is used when expanding the :default content type. Openapi doesn't support a default case so we need to list out all the supported content types.
The list could be fetched from muuntaja when we do #636
That said, this is probably not needed here, so I'll remove it.
There was a problem hiding this comment.
Actually, for the :post case it is needed since it uses a :default case.
There was a problem hiding this comment.
Removed one :content-types, added a comment for the other.
`#{}` isn't a valid :kind predicate
|
also fixed |
no need to insist on set, and many of our examples use vectors anyway
leftovers from #627
related to #84