Specifications

May 7, 2012 at 5:23 PM

I think it would be welcomed if specifications of the implementation would be declared.

I for myself would like to know for certain:

  • Which version of json-rpc is supported?
  • In case of http transport (the only one json-rpc.NET supports) what should the header look like. Content-type tag is of concern to me.
  •  Id in the request and response. What types are allowed? As I have observed it is string in json-rpc.NET. What are the official specs? is it integer or is it allowed to be string.

All in all I think json-rpc.NET has a great potential. I especially like the ease of use. I have set up working hello world in a matter of minutes. Json via MS WCF took me almost a whole day.

Coordinator
May 7, 2012 at 5:43 PM
Edited May 7, 2012 at 6:55 PM
and3rson wrote:
  • Which version of json-rpc is supported? We are currently targeting Json-Rpc 2.0 http://www.jsonrpc.org/specification
  • In case of http transport (the only one json-rpc.NET supports) what should the header look like. Content-type tag is of concern to me. Currently a few options: If RequestType=="Get", then contentType is ignored, and the Json-Rpc is expected to be in a parameter named 'jsonrpc'.
    If RequestTYpe=="Post" AND contentType == "application/x-www-form-urlencoded" the Json-Rpc is expected to be in a parameter named 'jsonrpc'.
    Otherwise the contentType is ignored, and the Json-Rpc is expected to be the entirety of the inputstream (excluding headers of course).
  •  Id in the request and response. What types are allowed? As I have observed it is string in json-rpc.NET. What are the official specs? is it integer or is it allowed to be string. I'll have to double check this, but I think it will Accept an Int as the ID but still returns a string. I'll get back with you on this later.

All in all I think json-rpc.NET has a great potential. I especially like the ease of use. I have set up working hello world in a matter of minutes. Json via MS WCF took me almost a whole day.

I appreciate your feedback, thanks!

Coordinator
May 7, 2012 at 7:08 PM
Edited May 14, 2012 at 3:29 PM

Update:

Quoted from 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]

The Server MUST reply with the same value in the Response object if included. This member is used to correlate the context between the two objects.

[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.

[2] Fractional parts may be problematic, since many decimal fractions cannot be represented exactly as binary fractions.

-----------

Json-Rpc.Net currently deviates from the spec here, as it will always return a string for the ID, even though it takes an Int. Though it also fails with an invalid Request when Id is passed as null, but ironically it will return a null in this situation.

This should be considered a bug, and will be addressed in a future release. -This has now been resolved

May 14, 2012 at 10:49 AM

Something to consider.

I have observed if [JsonRpcMethod] is declared as void and no exception occurs than the response does not contain a result neither an error member. This is not in accordance with specification. It should contain either result or error but not both

But the question is how should we handle void methods? Perhaps we could insert null as a result

Coordinator
May 14, 2012 at 11:47 PM

Maybe return Void.

I intially thought that no response would be fine, and it would IF they do not send an ID parameter. Buf if they do provide an ID parameter, then I think void may be more accurate then null.