Once you understand JSON-RPC’s Bits, you can assemble versions that match the different protocols.
In 1.0 a request object must always have all three fields. If you want a notification, you must set the id to null. The parameter must be an array of positional parameters. So a 1.0 request object always looks like:
A 1.0 response object contains both a result and an error, but one of them must be null:
Version 2.0 changed a lot of the protocol designs to be more client-server oriented. It added a new field to identify the specification version, allows reduced fields, and named parameters to be passed.
So a 2.0 request object could look like:
The response object could look like:
The specification version field was added to make sure the client got back a response type it would expect. The absence of a version field means it cannot reduce the fields and needs to send them with null values like the 1.0 version does.
Reduced fields was included to make a cleaner response structure. Not to reduce the default wire-text length. It also solved the issue of handling a call who’s result was null. Incorrect coding assumptions could cause error handling to trigger on a valid result of null in v1 . Reducing the fields protects against that by providing a cleaner structure and the check of existence vs assumed intent by value.