| It's a bit misnomer because it defines rpcs _and_ notifications. What people seem to be often missing for some reason is that those two map naturally to existing semantics of the programming language they're already using. What it means in practice is that you are exposing and consuming functions (ie. on classes) – just like you do in ordinary libraries. In js/ts context it usually means async functions on classes annotated with decorators (to register method as rpc and perform runtime assertions) that are event emitters – all concepts already familiar to developers. To summarize you have system that is easy to inspect, reason about and easy to use - almost like any other package in your dependency. Introducing backward compatible/incompatible changes also becomes straight forward for everybody ie. following semver on api surface just like in any ordinary package you depend on. Those straight forward facts are often missed and largely underappriciated. ps. in our systems we're introducing two deviations – error code can also be strings, not just numbers (trivial); and we support async generators (emitting individual objects for array results) – which helps with head of line blocking issues for large resultsets (still compatible with jsonrpc at protocol level, although it would be nice if they supported it upstream as dedicated semantic in jsonrpc 2.1 or something). They could also specify registering and unregistering notification listeners at the spec level so everybody is using the same scheme. |
The terminology is not ideal, I grant, but a JSON-RPC "notification" (a request with no id) is just a request where the client cannot, and does not, expect any response, not even a confirmation that the request was received and understood by the server. It's like UDP versus TCP.
> emitting individual objects for array results
This is interesting! How does this change the protocol? I assume it's more than just returning multiple responses for the same request?