Deciding whether to return a response

[bcb]

There's one more concern with JSON-RPC -- you shouldn't always return a response.

There are two reasons a response should not be sent:

• The request was a notification (no id was included).
• The request was a batch, and all requests in the batch were notifications (no id was included in any).

The question is how the developer API to handle this should look.

I'm thinking of a should_respond function which makes the decision for you based on the return value from dispatch, something like this (note synchronous protocols like http must return something)

from jsonrpcserver.response import should_respond

@app.route("/", methods=["POST"])
def index():
    response = dispatch(request.get_data().decode())
    return to_json(response) if should_respond(response) else ""

For async protocols something like:

response = async dispatch(request)
if should_respond(response):
    send(to_json(response))

Does this make sense? Would appreciate any thoughts.

[bcb]

Also, to be very strict, to_json would raise an exception if the request was a notification or batch of notifications. This way you must use should_respond before using to_json.

[st31ny]

If I understand the JSON-RPC specification correctly, the distinction between requests and notifications lies within the client only. So, while it might make sense in some cases in the server implementation to know whether a response is required (e.g., to avoid computationally intense calculations), I'd rather want the server implementation to handle that part of the communication alone.
TL;DR: I think server method implementations should not need to worry about the request/notification distinction. This should be handled in the server.

[bcb]

It’s not very nice to have

dispatch -> should_respond? -> to_json

I’d rather remove should respond but can’t think of another way.

[st31ny]

Yes, I agree. What about a None result? So to_json() returns None. Not very nice either but saves the if.

[bcb]

But then wouldn’t you still have to check the to_json result

[st31ny]

True. At least one check is required I guess since somebody needs to decide whether to send something or not at the end of the day.

[bcb]

Yeah, there’s no avoiding it.

It feels clunky but that’s the spec.

[hholst80]

I think one can avoid introducing a API method for this. Consider this:

@app.route("/", methods=["POST"])
def handler():
    response = dispatch(...)
    if response is None:
        return Response(status_code=HTTP_204_NO_CONTENT)
    else:
        return to_json(response)   # it must have been something we should reply to, error or not, and it has an Id.

The empty string "" is a proper response but if the content-type is application/json it could end up being interpreted as a completely empty document, which probably is not allowed by the spec (how would it be interpreted - how do you return Nothing in JSON?).

Ideas found here: fastapi/fastapi#717

If to_json throws an exception it's a bad thing, but it is not the responsibility of this library to solve it. ;-)

[st31ny]

Which is technically correct since JSON knows the value null and Python maps its None value to JSON null.

[bcb]

Yep.

Ok, so in an asynchronous protocol you should check the result of dispatch, and only send a response if the result is not None. But in HTTP it's not really necessary. You can just say

@app.route("/", methods=["POST"])
def index():
    return to_json(dispatch(request.get_data().decode()))

Which will return "null" to a notification.

[st31ny]

Looks good to me!

[bcb]

Maybe dispatch could just return the json, so there's no need for to_json.

In an async protocol like Websockets, you could check if the result is "null" and not respond if so.

I might make another topic about this.

[bcb]

Update: So we can't respond with "null" because although it's valid json, it's not valid json-rpc (the client will validate it against a json-rpc schema)

So it'll have to be an empty string (technically not valid json nor json-rpc, but we hope the client ignores this response)