Is there a more elegant way to define "no result" for a method

In my API I have some functions that do not return a result. I implement this by responding with a “null” value (but a “true” is just as good). The reason being that anything apart from success is an error, so I don’t need to return anything apart from “there is no error”.

E.g. (In pure JSON-RPC)

--> {"jsonrpc": "2.0", "method": "reboot", "id": 1}
<-- {"jsonrpc": "2.0", "result": null, "id": 1}

In the OpenRPC 1.2.6 specification however, a “result” property is required on a method, so I have to provide a name and a description etc, and yes I know I can use a $ref to a ‘#/components/null_result’ to save typing, but it would be much easier to not have “result” required, implying “null”.

Note: I am not trying to define JSON-RPC Notifications (no “id” field, no response expected, etc.) just allowing reasonably smart tooling to spot that there is no “result” defined, and just expect/respond with “null”.

My question is: are the spec authors happy with the status-quo of requiring an API to define a “null_result” component?

[zcstarr]

@ghostbuster91

According to the jsonrpc spec notification is just a request without the id field. Every jsonrpc method should handle both regular requests and notifications.

The suggestion I was trying to describe was a potential change to allow us to distinguish if a method is a notification or not. Currently our spec requires result field and does not have any affordance for saying something is not expecting a result at all and is therefore a notification.

In case of rest api we often signal that by an empty response with 404 error code. While jsonrpc can be used over http it doesn’t have to and so we don’t have the access on the protocol layer to http codes.

Agreed definitely don’t want to encode ay protocol specific things into the specification. Your options which is throw an error in the JsonRPC specified way or return result null are both valid options.

I would probably error on the side of specificity, returning null result, and reserve error for a case that represents an error. But that’s in the eyes of the api implementor.

Thanks for the heads up. I’d say file an issue on open-rpc playground and we’ll take a look at it over there. It should be supported, and if it’s not or erroring out in some way, happy to take a look and patch it up 😄.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.