Requests with null id property

[Andrew Arnott]

From relevant parts of the spec:

id

An identifier established by the Client that MUST contain a String, Number, or NULL value if included. If it is not included it is assumed to be a notification. The value SHOULD normally not be Null [1] and Numbers SHOULD NOT contain fractional parts [2] 

[1] The use of Null as a value for the id member in a Request object is discouraged, because this specification uses a value of Null for Responses with an unknown id. Also, because JSON-RPC 1.0 uses an id value of Null for Notifications this could cause confusion in handling. 

A Notification is a Request object without an "id" member. 

I gather that a request with an included "id" member is not a notification. Even if its value is null, it's still a request that expects a response. The spec discourages use of the null id value because that makes responses ambiguous between responses to unreadable ids and to a 'legitimately' null id. 

Is that how everyone else interprets it? Honestly it seems really weird that anyone would ever pass null as an id in a request as opposed to a number or string.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

[welfor...@gmail.com]

So, i would say this depends on your interpretation which means it probably needs clarity.

I would tend to follow your line of thinking and it is indeed strange and perhaps we instead of discouraging we outright prevent it and allow notifications to use NULL,
I would also say while we're looking at it we should perhaps look at support for array so a byte array could be sent to support 64bit numbers, however, that would mean more work for parsers as they would need to have a check for String, number or array if it's array covert it to 64bit number E.G Long Long in C++.

[Nathan Fischer]

that's how I interpret it, but honestly I wouldn't claim that my implementation supports it

[Matt (MPCM)]

Correct, the existence of the id member is the signal, not the value.

Why would someone send a null? ... probably by accident/error in a variable lookup/resolution at run time, but for the server role it should still respond with what it was given as an id value by the client.

[Andrew Arnott]

I'm glad folks share my interpretation. 

I suppose 'null' might be handy to be able to use if the client doesn't want to have to track an incrementing number and only sends 1 request at a time such that tracing the response back to the request is not necessary.

> perhaps look at support for array so a byte array could be sent to support 64bit numbers

Why would we need an array for that? I think on another thread recently I noticed a suggestion of encoding very large numbers in some non-decimal form. Why? 

All the libraries I use, and node.js itself, can parse a 64-bit integer encoded as decimal without a problem.