Correctly interpret explicitly null optional parameters

When dealing with nullable parameters, if the parameter is explicitly set to null on the client side, a parameter=null parameter is emitted and the server interprets it as a "null" string value, which does not correspond to what the client has sent.

This MR fixes this issue by not emitting the parameter if its value is set to null.

Original MR

Hello,I ran into an issue while dealing with optional parameters.In my application I have declared an optional parameter as such:
var name: String? by parameter()

When sending the request from the client, I sometimes explicitly set the parameter value to null. This is because my code looks like this:

suspend fun request(nameParam: String? = null) = httpClient.request(
  endpoint = MyEndpoint.searchByName,
  parameters = {
    name = nameParam
  }
}

But by doing so the parameter gets converted into a "null" string. Then, when accessing the parameter on the server side, I expect to get a null value but I actually get a "null" string value, which is incorrect.

There is a way to fix this on the client side which is to only set the name parameter if the value isn't null, but that adds a bit of avoidable extra code. And this doesn't solve the issue itself, which is that the value that is interpreted by the server isn't the one that we passed in the client. It also throws an exception when accessing the parameter if the parameter type isn't String.

I see a few solutions for this problem, each having their drawbacks:

  • The first solution, which is the one I have implemented in this MR, is to treat "null" string values as null when reading the parameter.
    • The drawback is that if for some reason we actually want to pass "null" as a string parameter, the server will wrongly convert it into null.
    • An alternative to this solution would be to use some sort of reserved value like "spine_null" which is very unlikely to be actually passed as parameter. It would look a bit "ugly" internally as we would be passing this value to the server as query parameter.
  • The second solution would be to not pass the parameter to the server if it is set to null.
    • The drawback is that in the case of an endpoint with an optional parameter which has a default value, the server wouldn't be able to differentiate between a null value or a default value. If we want to differentiate them, it would require internally passing the default value as a query parameter, which might go against the purpose of this library.

Let me know your thoughts on this and if you have a better idea on how to solve this problem.

Edited by skyecodes

Merge request reports

Loading