JSON-RPC consists of two specifically “shaped” object as well as rules around their use. The image below represents all the parts of both versions 1 and versions 2 of the specification. Above the line is the request object. Below the line is the response object.

JSON-RPC Request and Response Objects
Lets break down the concept step by step.
You need to call a function:

function
That function probably has some parameters:

parameter(s)
So what you want to perform on the server is this:

conceptual function
Multiple calls could be happening at the same time, so you need an identifier to pair up the response to the request:

id
If you care about the function call’s result you generate this object “shape”:

Request Object
If you don’t care about the function call’s result, it is called a notification. The result still gets generated, but the server will never send it back over the “wire”:

Notification Object
Notifications will NOT send back any rpc errors either!
Now, the purpose of a function call is usually to get a result back:

Result Object
But if something went wrong in performing the call (an RPC handling, processing, or permission error) you would need to handle the error:

Error Object
Either way, what comes back would look like:

Response Object
The only remaining data is the specification version property, which only exists after version 1.0 :

specification version
So your request object shape would look like the below:

request object
The response object shape would look like below:

response object
Those are all the bits. Next we can talk about the combinations and specification requirements.