Is it legit to add fields to a request object?

[Robert Poor]

Would the following be considered legal in JSON-RPC v 2.0?

{"jsonrpc": "2.0", "target":"xyzzy", "method": "update", "params": [1,2,3,4,5], "id":25}

As you might guess, the use case is specifying a destination node for a request.  I don't see anything the the spec that forbids adding fields to a request, yet that restriction may be implied.

Of course another approach is to wrap the whole thing:

{"target":"xyzzy", {"jsonrpc": "2.0", "method": "update", "params": [1,2,3,4,5], "id":25}}

but I find it a little odd that the id field is now at a different level than the target field, since both items are engaged in handling routing and responses.

What's the approved approach?

[Robert Poor]

typo:  The "wrapped" example should read:

{"target":"xyzzy", "message":{"jsonrpc": "2.0", "method": "update", "params": [1,2,3,4,5], "id":25}}

[Matt (MPCM)]

Personally... I think I would overload the value in the id or method field (ie. "method":"xyzzy:otherrandomstringid") in the request, essentially expressing the routing preference that way. The client already have an idea which node should be processing the message in an abstract sense. To me that sounds like part of the method name (resolution process).

jsonrpc server  'abccb' could also then easily reject messages meant for 'xyzzy' if they arrived incorrectly.

If they arrived at a normal server, the method is unlikely to exist and not result in speculative invocation.

There would be no approved approach as such, and most implementations 'should' not choke on additional fields, but reality may differ of course.

I've done something like this before, where clients are given tokens that are only valid for short windows against specific methods, and then only processed on the backend for very short windows, and delisted aggressively as 'spent' down. Sort of like short lived nonces in other protocols.

Not sure if your routing feels like that in nature... 

[Matt (MPCM)]

typo also... sigh.

(ie. "id":"xyzzy:otherrandomstringid")

or

(ie. "method":"xyzzy:update")

[Robert Poor]

@Matt: I like your suggestion of adding the receiver as part of the method name: recipient.verb is reminiscent of just about every object-oriented language, and makes semantic and syntactic sense.  Thanks!

--
You received this message because you are subscribed to a topic in the Google Groups "JSON-RPC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/json-rpc/BYv_s0XIfF4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to json-rpc+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/json-rpc/f69e1b72-ba9b-4041-acb6-2102e09e8bb4n%40googlegroups.com.

[Aleksandras Novikovas]

Specs does not explicitly forbid any other request members.

Therefore I would use your initial idea:

{"jsonrpc": "2.0", "target":"xyzzy", "method": "update", "params": [1,2,3,4,5], "id":25}

Member "target" would be an extension relevant to your server implementation (as specified in specs chapter 8).

You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to json-rpc+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/json-rpc/CAGHqdqXS7qrtAR8Lx%3DO0f9hGGtGVyjxFnJG7UbdiaAsDqGeDhA%40mail.gmail.com.