Skip to content

Serialization of spaceDelimited query parameter with a list of strings. #3550

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
iglosiggio opened this issue Feb 5, 2024 · 6 comments
Closed
Assignees
Labels
clarification requests to clarify, but not change, part of the spec param serialization Issues related to parameter and/or header serialization question
Milestone

Comments

@iglosiggio
Copy link

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 information
  • Hello%20World Nice%20to%20see%20you: Doesn't follow from the examples on the spec
  • Hello 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.
@handrews handrews added question param serialization Issues related to parameter and/or header serialization labels Feb 6, 2024
@miqui
Copy link
Contributor

miqui commented Feb 7, 2024

@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&paramName=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.

@miqui
Copy link
Contributor

miqui commented Feb 7, 2024

@handrews - perhaps this one is a candidate (once we decide on the correct wording, etc) that could be migrated to MoonWalk. Thoughts?

@iglosiggio
Copy link
Author

iglosiggio commented Feb 7, 2024

@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!

@handrews
Copy link
Member

handrews commented Feb 7, 2024

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

@handrews handrews added the clarification requests to clarify, but not change, part of the spec label Feb 7, 2024
@darrelmiller
Copy link
Member

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.

@lornajane
Copy link
Contributor

Fixed in #3723 and #3754 and #3755 (thank you @handrews !) so I'll mark this as resolved.

@handrews handrews added this to the v3.0.4 milestone May 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification requests to clarify, but not change, part of the spec param serialization Issues related to parameter and/or header serialization question
Projects
None yet
Development

No branches or pull requests

5 participants