RPC 2.0 will be a major refactor of the existing RPC, targeted for V22. The refactor will be a breaking change, and RPC 1.0 will be deprecated but usable for a few more versions. The goals of RPC 2.0 are as follows:
Remove unused RPCs, make changes that require breaking the existing functionality, and add new RPC functionality
Improve performance, both internally and in the endpoint
Consistent input and output handling
This topic will outline the proposed, accepted and rejected RPC changes from the point of view of the user, i.e., internal changes are out of scope.
I occasionally spot confusing RPC responses. For example,
"error": "Unable to parse JSON"
sometimes means "request doesn't include all the mandatory parameters"
Another candidate is
"Account not found"
which shows on send if the account is not opened on the ledger yet, whereas the error message makes it look like the account is not part of the wallet
This might be part of "No JSON-escaped strings", or moving to a different protocol like protobuf, but if a method like pending returns an empty array, it should be an empty array not a string. That's one of the biggest issues when using a typed JSON framework with the RPC. This, and other issues with the current JSON library, are tracked here on GitHub: https://github.com/nanocurrency/nano-node/issues/1871
Great ideas and remarks, thanks! The first one will have to be evaluated, but the second one is likely to happen, splitting into account_not_found and account_not_found_in_wallet errors makes perfect sense.
Oh thank goodness. I feel less incompetent now.
A local dev and I were working on ping-ponging a bunch of high-velocity, conditional transactions between various accounts over the summer and kept getting confused on some of the output of "account_info".
We eventually moved to other RPC calls, but never quite straightened out what we were trying to accomplish.
Had an integration ask about whether there was an RPC that you could get the block details based on the account and block height. Unsure of the specific use case there, but perhaps that is worth exploring in the next version.