Json-rpc request as recursive type

[Alex Korotkov]

Hi, fellows.

Can json-rpc request be a recursive type?

it can be helpful to do sum calculation without additional client to server roundtrips.

I want to do it like this:

{ "jsonrpc": "2.0", "method": "sum", "params": [ {"jsonrpc": "2.0", "method": "get-a", "id": "2"}, {"jsonrpc": "2.0", "method": "get-b", "params": [1,2,4], "id": "3"} ], "id": "1" }

[Brad Jones]

I don't think the spec really addresses sub-requests, which is what I think you really want here, but I suppose there's no reason your server implementation can't.

[Alex Korotkov]

I think that this should be fixed in spec. 

Because if I want to provide such implementation,  it will conflict with this:

4.2 Parameter Structures

• If present, parameters for the rpc call MUST be provided as a Structured value. Either by-position through an Array or by-name through an Object.

  • by-position: params MUST be an Array, containing the values in the Server expected order.
  • by-name: params MUST be an Object, with member names that match the Server expected parameter names. The absence of expected names MAY result in an error being generated. The names MUST match exactly, including case, to the method's expected parameters.
    
    

if I just pass a subquery as an object to method call, it will be recognized as a by-name parameter passing.

So, I propose this update:

4.2 Parameter Structures

If present, parameters for the rpc call MUST be provided as a Structured value. Either by-position through an Array or by-name through an Object.

• by-position: params MUST be an Array, containing the values in the Server expected order.
• by-subrequest: params MUST be an Object that represents as jsonrpc2 request with id. Results of nested method calls including errors should be provided to wrapper call.
  
• by-name: params MUST NOT be a subrequest, params MUST be an Object, with member names that match the Server expected parameter names. The absence of expected names MAY result in an error being generated. The names MUST match exactly, including case, to the method's expected parameters.

вторник, 24 октября 2023 г. в 23:24:15 UTC+3, br...@bradjonesllc.com:

[Matt (MPCM)]

Hi,

'Fixing' the spec is not the right way to approach this, and sub-request concepts are complicated and often flavored with implementation opinions (ie. this works easily in java and python, so why not include it).

You essentially want a custom method, which understands parsing/processing/ordering/processed-response-injection. This did come up in the old news group *ages* ago. There are too many variants/desired-expected-fallback-behaviors to settle on one implementation, and nothing about this fits with "It is designed to be simple!".

At the time, I think the suggestion to implement the composition-structure-processing method, build up your composition/logic structure, make a single call with that structure, have the server method be able to understand it and process it and return a single result. Moving this down into the base spec layer offers little additional advantages.

That said, I'd encourage you to implement it and see how the you find the results/experience, and come back here to share that and promote such a change if you still feel as strongly. I am not in favor it for the spec, but in the right situations the concept is interesting, but saving a network call is usually not the reason to do this.

Real world (ish) examples are appreciated, since sum is not really a compelling example of such a need. :)