style: form + object looses the parameter name?
See original GitHub issueHi, while preparing a presentation of the new features of OpenAPI 3.0, I stumbled over this line in the parameter style examples table:
style |
explode |
… | object |
|---|---|---|---|
| form | true | … | R=100&G=200&B=150 |
So if I have a parameter color with an object { "R": 100, "G": 200, "B": 150 } to be passed as a query parameter (which has default style form, and default explode value true), I get a query of ?R=100&G=200&B=150 – no trace of the parameter name color in here anymore.
If I have two such parameters (e.g. "foregroundColor": { "R": 100, "G": 50, "B": 150 } and "backgroundColor": { "R": 200, "G": 250, "B": 200 }), they would passed as ?R=100&G=50&B=150&R=200&G=250&B=200, from which no server could reliably derive the actual parameters.
Is it really meant to be that way? I guess this is how RFC 6570 defines “form style query expansion”, but it will work only if there is only one of those parameters with object schema at all, or if they have non-overlapping property name sets (though having to implement that seems ugly).
Issue Analytics
- State:
- Created 6 years ago
- Comments:9 (5 by maintainers)

Top Related StackOverflow Question
Good catch. The answer, to me, seems to be ‘yes’. Let’s face it, there’s no elegant way to solve this. We’re trying to mix and match cases here, and some may not make sense. How would you solve that?
Like you said, the RFC defines the behavior just like that, so let’s leave it as it is. Tooling will have to deal with it, and I’d suggest just clobbering values. It’s really up to the user to define things that make sense, within the defined behavior.
Authoring tools might be able to provide warnings to users in such a case.
Further affirming my point is that you can’t (or at least shouldn’t) use URI templates for header or cookie parameters. RFC 6570 expects to only be used for URIs and therefore specifies percent-encoding for simple and form-style templates, but headers are not URIs and shouldn’t be encoded that way. Nor should cookies be exploded using an ampersand delimiter, because RFC6265 requires a semi-colon. And if you combine the original post’s issue about parameter name erasure with the default for cookies being
explode: true, it’s clear that URI templates are not a reasonable serialization strategy for cookies.So if you take out headers, cookies,
deepObject,allowReserved,pipeDelimited,spaceDelimited, andexplode: trueform objects, you now have very few parameter definitions left that URI template tooling is actually appropriate for.