search

jakartaee / rest

Jakarta RESTful Web Services
Other
353 stars 114 forks source link

Behavior of 'queryParam' method of 'UriBuilder' class when the 'values' ​​parameter is passed as an empty array #1092

Open winie opened 2 years ago

winie commented 2 years ago

The queryParam method of the UriBuilder class can also be called with the 'values' ​​parameter without arguments. So the 'values' ​​array would be empty.

Is the query parameter appended to the URI without a value?

uriBuilderInstance.queryParam("someQueryParamName");
// www.foo.com/bar?someQueryParamName

Or is the query parameter ignored?

uriBuilderInstance.queryParam("someQueryParamName");
// www.foo.com/bar

Can this be clarified in the javadocs please.

winie commented 2 years ago

In my opinion, the query parameter should be appended to the URI without a value: www.foo.com/bar?someQueryParamName

Because the queryParam method at least handles the name parameter. That the method call doesn't change anything about the URI is counterintuitive.

mkarg commented 2 years ago

What is your intention of this issue: Do you want to know what a particular implementation actually does, what the spec mandates that all implementations MUST do, or do you want to propose a spec change according to your personal preference?

winie commented 2 years ago

Sorry, I might have been unclear with my description of the problem. I want all implementations to behave the same way, when an empty values array is provided. Like I wrote in my first post, when no value is available a query segment is added, whereas a second possible outcome might just ignore the parameter and no query segment is added to the URL. Both outcomes are randomly possible when a no values parameters is present. I would like this to be reduced to one specific kind of outcome, no matter the implementation.

mkarg commented 2 years ago

@jansupol @andymc12 @ronsigal WDYT?

jelemux commented 1 year ago

I agree that the spec should define how this is handled. However, this would be a breaking change. Maybe we could take a look how the implementations handle this. If they all do it the same way, we could define it that way in the spec without causing anything to break. Technically it would still be a breaking change though and there could be more implementations that we don't know of.