OAI
Encoding object has style and contentType
Let's say I have:
requestBody:
content:
application/x-www-form-urlencoded:
schema:
type: object
properties:
address:
type: object
properties: {}
encoding:
address:
contentType: "application/json" # This is the default
style: form # This is the default
explode: true # This is the default
Since encoding has both a contentType and a style, what do I do with the address property? Do I decode it as an exploded form object? Do I extract the value of 'address' from the message body and run it through JSON.parse()? Do I decode it as an exploded form, but run the value of each key through JSON.parse()?
Or does contentType here only apply to multipart bodies?
OK, digging through this more, it was actually fixed in 3.1.0 with the following new text added to style (which, along with explode (but not allowReserved), was extended to support multipart/form-data as well):
If a value is explicitly defined, then the value of contentType (implicit or explicit) SHALL be ignored.
So that at least explains how to override contentType (default or otherwise). The implication is that if it's not explicitly defined then contentType wins... I guess? The style text still references query params for default values, so it's still not entirely clear, nor is it entirely clear what is supposed to happen in 3.0, but that's at least a clue.
Since allowReserved was not extended to form-data, then there needs to be a way to not use RFC6570 value expansion (with its automatic percent-encoding), so I'm going to interpret this to mean that despite the wording around defaults, part of this is changing the behavior when no explicit style is defined.
This is going to take more investigation and thought to fully unravel.
@OAI/tsc review request: It's unclear how to clarify 3.0.4 here. Even 3.1.1 is a bit murky, but the only thing I can think of for 3.0.4 is to more-or-less backport the 3.1.1 behavior. Or maybe deem the area implementation-defined (where implementations can choose which of two options to support) while making the 3.1.1-compatible behavior RECOMMENDED?
We can only recommend the 3.1.1 behavior in a patch version, so let's do that.
After a great deal of GitHub archaeology, I've determined that the intent was for contentType vs style to provide approximate parity with the Parameter Object's content vs schema. A PR is forthcoming (the previously linked PR included a bit, but I split it out as it needs a more thorough explanation and is better handled separately).