Omit params field from requests instead of sending null value

[selu]

Based on the specification, the request's params must be an array or an object if it exists, so sending a null value is not valid. Actually, it causes errors for KODI JSONRPC server with requests without any parameters. That's why I tried to find a way to fix this issue.

The solution is very simple, just I haven't updated the comments for the params field.

[tomusdrw]

@selu thanks a lot! This looks indeed sensible. Do you mind adding an additional test case to make sure that the server side of the library is correctly converting missing params into None?

I think adding a reverse test case (i.e. deserialize without params) would suffice, unless I didn't see we already have a testcase like that.

[niklasad1]

Thanks, I agree with your interpretation of the spec.

I suggest additional tests for jsonrpc derive (if possible):

1. a method without params: fn a() -> BoxedFuture
2. a method with optional param: fn b(p: Option<usize>)

[selu]

@tomusdrw , I found the test case for deserialize without params, it is the last item of fn call_deserialize() between lines 263 and 273 in file core/src/types/request.rs

[selu]

Thanks, I agree with your interpretation of the spec.

I suggest additional tests for jsonrpc derive (if possible):

1. a method without params: `fn a() -> BoxedFuture`

There is already a test case for empty params in derive/tests/macros.rs

#[rpc]
pub trait Rpc {
	/// Returns a protocol version.
	#[rpc(name = "protocolVersion")]
	fn protocol_version(&self) -> Result<String>;
…
fn should_accept_empty_array_as_no_params() {
	let mut io = IoHandler::new();
	let rpc = RpcImpl::default();
	io.extend_with(rpc.to_delegate());

	// when
	let req1 = r#"{"jsonrpc":"2.0","id":1,"method":"protocolVersion","params":[]}"#;
	let req2 = r#"{"jsonrpc":"2.0","id":1,"method":"protocolVersion","params":null}"#;
	let req3 = r#"{"jsonrpc":"2.0","id":1,"method":"protocolVersion"}"#;

However, this checks another cases too.

2. a method with optional param: `fn b(p: Option<usize>)`

I could not find test case for optional param, probably it worth it to add one. Would it be ok in the same file in a similar way?

[niklasad1]

I could not find test case for optional param, probably it worth it to add one. Would it be ok in the same file in a similar way?

Yes, just make a new unit test for it in that file should be fine

[selu]

@niklasad1 , test is added for the optional parameter, please review.

[niklasad1]

I would like to add requests with "params":[] and "params":null here otherwise looks great

[selu]

Added those variations to the test case.

[tomusdrw]

Shouldn't this be rejected as invalid?

[selu]

It's a good question, I know only KODI jsonrpc server, that rejects only "params":null variation, but accepts both "params":[] and "params":{} as an empty parameter.

[tomusdrw]

I'd distinguish 3 different cases:

1. Method expects positional arguments (either 0 or some being optional)
2. Method expects named arguments (either 0 or some being optional)
3. Method expects raw arguments

In case (1) IMHO only params: [] should be accepted, similarly in case (2) only params: {} should be accepted. In both cases omitting params should be rejected.
In the 3rd case we can accept any combination, since it's up to the method to handle the raw parameters being passed.

Regarding params: null I'm wondering if that should be forbidden completely, since it's not really part of the spec.

[niklasad1]

In both cases omitting params should be rejected.

hrm, really? In the client code Params::None would rejected then?

Regarding params: null I'm wondering if that should be forbidden completely, since it's not really part of the spec.

I'm fine with that and it might better to be explicit, mainly because it might be possible that a request contains the wrong type/format and the default value is then used without that the caller gets informed by that....

[tomusdrw]

hrm, really? In the client code Params::None would rejected then?

I was checking the code and it might not be what we do now. AFAICT in case of optional parameters we parse None correctly as well. Anyways, I think this discussion is a bit tangential to that particular PR, so let's open an issue and discuss there.

The code in PR is an improvement for the client side for sure, we might want to follow up on how we want the server to behave separately.