Questions about names for query parameter values

[bodawei]

I'm finding some of the examples for serializing query parameters a little confusing in the 3.0.2 spec.

Given this portion of the examples:

style	explode	empty	string	array	object
form	false	color=	color=blue	color=blue,black,brown	color=R,100,G,200,B,150
form	true	color=	color=blue	color=blue&color=black&color=brown	R=100&G=200&B=150
spaceDelimited	false	n/a	n/a	blue%20black%20brown	R%20100%20G%20200%20B%20150
pipeDelimited	false	n/a	n/a	blue|black|brown	R|100|G|200
deepObject	true	n/a	n/a	n/a	color[R]=100&color[G]=200&color[B]=150

• For form, I see we are always listing a parameter name (color, or R, G and B, as appropriate).
• For deepObject, I see we also have parameter names (color[R], color[G], color[B])

Questions:

• spaceDelimited and pipeDelimited however don't have names. I'd expect these should actually be:
  • color=blue%20black%20brown
  • color=R%20100%20G%20200%20B%20150
  • color=blue|black|brown
  • color=R|100|G|200|G|150

[hkosova]

This part of the OpenAPI Specification is inconsistent - the Style Values section defines the spaceDelimited and pipeDelimited behavior for arrays only and not for objects, but the table still shows object examples. This was previously discussed in #1508:

dekryptic commented
2. Also, under the "Style Values" table, should the types for simple be primitive, array, object and the types for spaceDelimited and pipeDelimited be array, object? You have examples for these styles and types in the next section.

darrelmiller commented
2. For simple, primitive is the same as an array of one. For object the behavior is undefined. I think the behaviour should be the same for pipeDelimited and spaceDelmited.

darrelmiller commented
2. I said undefined, but I sort of lied. OAS doesn't explicitly define what to do with objects that are not exploded, but 6570 does and that is what the example shows. See https://tools.ietf.org/html/rfc6570#section-3.2.2 I'm not really sure we want to specify that behavior because it really isn't very useful.

[bodawei]

@hkosova I agree with you about the inconsistency.

Do you know what's the right way to deal with this? That is, it seems like it's unfortunate that the spec has problems in it, especially if there's some resolution about it in the issues here. It would be beneficial to all if these were eventually addressed. I see they haven't been addressed in the 3.1.0-dev branch, so I could, for example, submit a PR with my best interpretation of the conclusions in the threads.

[handrews]

#3737 is a duplicate of this, which I did not realize, but now it has more discussion and several PRs attached to it. Closing this in favor of that issue - the examples will be fixed in 3.0.4, 3.1.1, and 3.2.0, as tracked through #3737.