Clarification regarding VOID return type

[Vladimir Dzhuvinov]

Greetings,

I've got a few Java method to export via JSON-RPC and some of them
have a void return type. The methods are not meant to be
"notifications" (in the context of JSON-RPC).

What is the correct way to structure the response JSON, for version
1.0 as well as for 2.0?

Vladimir

[Alexandre Morgaut]

Well, I think the best result would be an empty object: {}


On Sep 26, 6:23 pm, Vladimir Dzhuvinov <vladimir.dzhuvi...@gmail.com>
wrote:

[Roland Koebler]

Hi,

Note that JSON-RPC only defines the protocol; it does not (and should
not) define language-specific implementation-details.

But in my opinion, the best way for "no return value" would be to return
null (both in 1.0 and in 2.0).

e.g.:
- JSON-RPC 2.0: {"jsonrpc": "2.0", "result": null, "id": 1}
- JSON-RPC 1.0: {"result": null, "error": null, "id": 1}

regards,
Roland

[Alexandre Morgaut]

> But in my opinion, the best way for "no return value" would be to return
> null (both in 1.0 and in 2.0).

Well my first thought was also for null but people often expect
procedure not intended to return a value, return true or false to say
if it processed well or not

So if this kind of procedure return {} when there was no error it will
be interpreted as true, otherwise the result property won't exists and
will return undefined that will be interpreted as false.

If it return null when the call was successful, the client will have
to check between undefined and null or to check if the error property
is undefined or null (JSON-RPC 2 or 1). It's a little more work to do
(even if often preferable)

[Roland Koebler]

Hi,

> Well my first thought was also for null but people often expect
> procedure not intended to return a value, return true or false to say
> if it processed well or not

If the return-value should tell the user whether the procedure was
"successful" or not, then the procedure should return such a value;
but if the procedure does not have a return-value, then the user may
not use the return-value in crude ways but has to read the
procedure-documentation.

> So if this kind of procedure return {} when there was no error it will
> be interpreted as true, otherwise the result property won't exists and
> will return undefined that will be interpreted as false.

No! This is wrong (and additionally very bad practice).
Remember that JSON-RPC is language-independent. You may not assume
that the client uses the same progamming-language as the server!

So:
- True, False, "undefined" and an empty dictionary are completele
different values.
If you e.g. try to convert an empty dictionary ("{}") to a boolean
value, some languages may return True, others return False and others
may even throw an exception/error etc.
- If a procedure without a return-value wants to report an error in a
JSON-RPC-Response, it has to use the "error"-field.

> If it return null when the call was successful, the client will have
> to check between undefined and null or to check if the error property
> is undefined or null (JSON-RPC 2 or 1). It's a little more work to do
> (even if often preferable)

A JSON-RPC-Client *always* has to check the Response, and its "result"-
and "error"-fields.

regards,
Roland

[Vladimir Dzhuvinov]

Thanks for the clarification.

I see there was some confusion here regarding how success and failure
of a general function/method call should be indicated. I think a lot
of this confusion stems from programming languages that don't support
exceptions. So in such a situation the programmer often ends up
"overloading" and "abusing" the return type as a mean to signal errors
too. For example, suppose you've got a function that adds two numbers:

c = add(a, b)

"c" is the result (the sum), but what if the addition fails for some
reason (overflow), how do we signal that? To handle such a situation
we may choose to return a null result which distorts the true meaning
of "c" (being a sum, a number, not an error variable); or, as it is
done in some languages (that support passing references), we may
change the function signature to include an explicit error flag, which
doesn't look a lot better either:

c = add(a, b, error)

or

error = add(a, b, c)


Fortunately, today we've got languages that support exceptions, so
with them the return type can have its proper meaning, and errors are
signaled separately via thrown error objects, e.g.

try {
c = add(a,b);
} catch (error) {
// addition failed
}

As for Java, exporting a class method via JSON-RPC is relatively
straightforward in terms of result/error mapping - the return type
becomes the result (or void becomes null as I know now), and thrown
exceptions are rewritten as a JSON-RPC error.


Regards,

Vladimir Dzhuvinov

[Alexandre Morgaut]

Well I often think for scripting language users.
These are mostly said "poorly typed" or in better words "dynamically
typed".
One of the purpose of these language is to facilitate their usage with
automatic conversions, and even if it sometimes look a bit scary, some
developers like it and optimize their code with it. This ability also
helped people to be quickly able to provide working code.
Exceptions and error property existence control are surely better in
professional context, but one thing I learned is :
"try to make it simpler for the simplest while you can still use it
professionally with more detailed features.

About Voids

JSON-RPC 2 propose :
- function handling returning values
- notification process without returning values

Why void could not fit in them ?

If the purpose is to know if all worked well, the void could be turned
into a function returning true or false
-> that's would be a huge work to publish hundreds of existing methods
over JSON-RPC (without thinking of backward compatibility)
When a void fail it can send an exception. This way the error can be
return "If its not a notification" So what returned a value when it
worked...
Here you probably ended when you sent your question

My other problem with null is that its still a meaning value to me but
required in JSON-RPC 2 because of this :
"result
Required on success, omitted on failure."

I think it would be reasonable to consider that procedure not meant to
be notification could be written as :
{"jsonrpc": "2.0", "id": 4}
instead of
{"jsonrpc": "2.0", "result": null, "id": 4}
It's kind of inconsistent to have a result property in a response
which is not intended to send a result.

The problem is just that without "result" or "error" property, this
kind of message has no semantic at all meaning it is a "response"
But as request and notifications all have a method property, and as
these messaged are not delivered nor interpreted by the same
components (client or server), it might be acceptable.

[Vladimir Dzhuvinov]

Salut Alexandre,

> My other problem with null is that its still a meaning value to me but
> required in JSON-RPC 2 because of this :
> "result
>     Required on success, omitted on failure."
>
> I think it would be reasonable to consider that procedure not meant to
> be notification could be written as :
> {"jsonrpc": "2.0", "id": 4}
> instead of
> {"jsonrpc": "2.0", "result": null, "id": 4}
> It's kind of inconsistent to have a result property in a response
> which is not intended to send a result.

This actually makes a lot of sense. Skipping the result altogether
seems semantically a lot closer to the meaning of void functions than
setting a null result.

So, on success, do we really need to have a result at all times?

In terms of error detection, it suffices to check the "error" property
only. If it's defined (property exists and it's not null) then the
request failed, otherwise the request was successful. Actually, this
is how I check for RPC request errors in my own code. The spec's
insisting on "result defined" EXOR "error defined" seems kind of
redundant to me.

What do you guys think?


Vladimir Dzhuvinov

[Brian Dilley]

jsonrpc4j returns null

[Matt (MPCM)]

http://en.wikipedia.org/wiki/Void_type

Either the jsonrpc server itself could convert from void to null or
you could expose a wrapped function...

My reaction is that it should return null as the value of the result
property. It is important that the core meaning of any call be
preserved within the types provided by json.

Visual basic used to split it by having subroutines that did not
return values and functions that did...
PHP can return; with no arguments, but it would result in a null.

--
Matt (MPCM)

[Vladimir Dzhuvinov]

> My reaction is that it should return null as the value of the result
> property. It is important that the core meaning of any call be
> preserved within the types provided by json.

Alright, Matt, I think I got it now :)

The result is reported in whatever JSON type comes conceptually
closest and JSON null is the best possible match of void.


Vladimir Dzhuvinov