Open hkosova opened 4 years ago
@hkosova the use cases definitely match here, as parameters are by definition strings, and any other aspect of their structure is encoded into the string.
However, I remember running into some sort of trouble trying to square the usage of Media Type Objects, Encoding Objects, and the content*
keywords for multipart requests/responses and/or file uploads.
Another potential wrinkle is that normally you'd expect a JSON string, and therefore need to decode escaped double quotes and backslashes as you parsed the JSON value (but nothing else that's a legal JSON character would need decoding). In this case, the string needs to be parsed/decoded according to URI query string rules, which are somewhat different. I think it is acceptable to wave our hands here a bit and say that the context (parameter object with in: query
) is how you determine how to decode the string. (This whole paragraph is me thinking out loud, if it's not entirely clear I'm happy to answer questions but it might just be that I'm still thinking through it.)
JSON Schema 2019-09 has the
contentSchema
keyword whose purpose and functionality seems to be the same as that ofcontent
in Parameter Objects.Should Parameter Object's
content
be deprecated in favor of JSON Schema'scontentSchema
keyword?Example:
OAS 3.0:
OAS 3.1 + contentSchema: