JSON-RPC

JSON-RPC separates the format of a remote call from the network technology carrying it. A client sends a JSON object naming a method and optionally supplying parameters; a server returns a result or an error object. The specification is transport-neutral, so implementations can use HTTP, WebSockets, raw TCP, Unix sockets, or other channels, provided both sides agree on framing and delivery behavior.¹

Version 2.0 identifies messages with a required jsonrpc member whose value is "2.0". It followed the earlier 1.0 design by making notifications, batches, structured errors, and explicit version marking part of a more rigorous protocol. JSON itself supplies the serialization rules, but JSON-RPC does not define application-level types, authorization policy, or a universal service-discovery mechanism.¹²

A request contains jsonrpc, a method name, an optional params value, and an id used to correlate the response. Parameters may be an array of positional values or an object of named values. The response carries the same identifier and contains exactly one of result or error; an error includes a numeric code, a human-readable message, and optional implementation-defined data.¹

A notification omits the identifier and requires no response, making it useful for events or commands where acknowledgement is unnecessary. A batch is a JSON array containing multiple requests or notifications, and responses need not preserve request order. The specification defines parse-error, invalid-request, method-not-found, invalid-params, and internal-error codes, while reserving a range for server-defined errors. It does not prescribe whether calls are synchronous, concurrent, retried, or transactional.¹

JSON-RPC provides message semantics but not a complete communications stack. An HTTP implementation must decide how it maps calls to HTTP methods, status codes, content types, streaming behavior, and connection failures; a WebSocket implementation must establish its own connection and origin policies. The JSON syntax is standardized separately by the IETF, including rules for objects, arrays, strings, numbers, and null values.²

Security therefore depends heavily on the host protocol and service. Deployments commonly need authentication, authorization for individual methods, input validation, rate limiting, size limits, and protection against replay or cross-site requests. Exposing a powerful method namespace without those controls can turn a seemingly simple endpoint into administrative remote access. JSON-RPC itself supplies no encryption, identity system, or permission model.

JSON-RPC is often embedded inside larger domain protocols rather than used as a visible standalone product. The Language Server Protocol uses JSON-RPC messages to connect editors with language servers, allowing diagnostics, completion, navigation, and refactoring features to run in separate processes.³

Blockchain interfaces also use the format extensively: Ethereum clients expose methods such as querying account state and submitting transactions through a JSON-RPC API, while Bitcoin Core provides a separate RPC interface for node administration and wallet operations.⁴ These examples demonstrate an important boundary: JSON-RPC standardizes the envelope, but the method names, parameter schemas, result meanings, batching conventions, and operational risks belong to each application. Reserved method names beginning with rpc. are intended for protocol extensions and should not be used for ordinary application methods.¹

Notification

A request without an identifier; the server must not send a JSON-RPC response.

Batch

A JSON array containing multiple requests, notifications, or both.

Request identifier

The value that correlates a response with its request; it may be a string, number, or null, although null is discouraged for ordinary requests.

Transport

The communication mechanism carrying JSON-RPC messages, such as HTTP, WebSocket, or a local socket.