Multiple Different Styles for Query Parameters

Is it possible to have multiple different styles for query parameters under the same path/operation? This mostly relates to explode. For example, would something like this make sense:

/users?id=3|id=4|id=5&q=1

[darrelmiller]

I hadn’t seen those docs. In my opinion that example is wrong. One of the goals of the changes that were made with OAS 3.0 was to try and make the parameter serialization align as closely as possible with RFC6570 without breaking backward compatibility. The Style concept encapsulates two different things from 6570, the separator and the prefix. Characters like the dot, semi-colon and slash are prefixes and commas are separators in 6570. The explode operator (which is concept taken directly from 6570) causes the prefix and key= to be repeated for each value. It isn’t related to the separator. So, when you mix styles with different prefixes, the serialization is fairly straightforward.

Consider the template:
{/segments*}{;coords*}{?params*}

where segments = [“foo”,“bar”]
coords = {“x”: 2 ,“y”: 3] params = {“sort”: “up”, “view”: “minimal” }

you would get:

/foo/bar;x=2;y=3?sort=up&view=minimal

Now only a subset of 6570 is supported currently in OAS, so you can’t actual represent the above template yet. However, the serialization rules should attempt to follow 6570 where possible. Note that the ? prefix is special in that the first value gets a ? and subsequent ones get an &. You can also use the & prefix where every value gets the & prefix.

For Pipe and Space delimiting, it should play the same role a comma plays in 6570. i.e. it should separate values when they are not exploded. I see no value in introducing more capability that is incompatible with 6570. Ideally, I would like tooling folks to be able to use existing off the shelf 6570 libraries. I see no reason for us to have to reinvent URL construction code.

[darrelmiller]

@dekryptic 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.

1. Welcome to the challenge of 6570. It works pretty well for serialization. It sucks royally for deserialization. It wasn’t intended to work for deserialization. We are at the mercy of URL designers to create URLs that don’t suck.