OpenAPI-Specification
OpenAPI-Specification copied to clipboard
Serialization of `spaceDelimited` query parameter with a list of strings.
The specification says that spaceDelimited should be used for array or object values. How should an space be escaped when serializing into this format?
Example
Given the array ["Hello World", "Nice to see you"] serialization of this value using the spaceDelimited style is not properly defined.
Options
Hello%20World%20Nice%20to%20see%20you: Looses informationHello%20World Nice%20to%20see%20you: Doesn't follow from the examples on the specHello World%20Nice to see you: Is not valid as a query parameter. If we URLEncode again then the separator ends up URLEncoded twice.Hello%2520World%20Nice%2520to%2520see%2520you: Encodes the array items twice. I think this is the most reasonable option but it is a bit weird.Hello%20World%2520Nice%20to%20see%20you: Ecodes the separator twice.
@iglosiggio - let me stake a stab at this. I too agree this is not clear, so, I end up not using this part of the spec to describe the API. I have tried APIs like so: api/phrases?phrase=hello world&phrase=Nice to meet you
you'll end up wtih: ?paramName=Hello¶mName=Nice%20to%20meet%20you
and then have the API code roll up all the values internally into an array.
Here is another example: /authors?name[]=miguel&name[]=quintero
Again, this does not address your concern exactly, but perhaps it "gets you going".
I'll raise this during this week's community call.
@handrews - perhaps this one is a candidate (once we decide on the correct wording, etc) that could be migrated to MoonWalk. Thoughts?
@iglosiggio - let me stake a stab at this. I too agree this is not clear, so, I end up not using this part of the spec to describe the API. I have tried APIs like so: api/phrases?phrase=hello world&phrase=Nice to meet you
I understand that. We are building some internal tools that expect to use API specs in order to make HTTP requests.
Here is another example: /authors?name[]=miguel&name[]=quintero
Is that the correct encoding for style=deepObject, explode=true?
I'll raise this during this week's community call.
Thanks!
@miqui this is just a clarification of what the existing spec means. It can go in a patch release (3.0.4/3.1.1) or even on the Learn site.
We discussed this at the TDC meeting. Additional guidance is needed to let the developer know that they are responsible for pre-encoding parameter values so that characters do not conflict with the chosen delimiter.
Fixed in #3723 and #3754 and #3755 (thank you @handrews !) so I'll mark this as resolved.