JSON-RPC（ジェイソン・アールピーシー）は、JSONを用いてリモートプロシージャコール（RPC）を行うためのシンプルかつ軽量なプロトコルです。2005年頃に最初のドラフトが公開され、2010年にJSON-RPC 2.0として安定化された経緯を持ちます。リクエストはjsonrpc・method・params・idという4つのキーを持つJSONオブジェクトで表現され、レスポンスは結果を表すresultキーまたはエラーを表すerrorキーのいずれかを返すという、最小限の仕様で構成されています。HTTPだけでなくWebSocket・TCP・標準入出力など多様なトランスポート上で利用でき、Ethereum・BitcoinなどのブロックチェーンノードやLanguage Server Protocol（LSP）など、現代的な領域でも採用が広がっているのが特徴です。
この記事の目次
- JSON-RPCを支える3つの中核要素
- JSON-RPCを利用する基本フロー
- JSON-RPC運用で押さえる注意点
- JSON-RPCとRESTの設計思想の違い
- まとめ
JSON-RPCを支える3つの中核要素
JSON-RPC 2.0のメッセージは、Request・Response・Notificationという3種類のいずれかに分類されます。Requestは「jsonrpc」: 「2.0」、呼び出すメソッド名、パラメータ（配列または名前付きオブジェクト）、そしてレスポンスと突き合わせるためのidという4要素を含み、サーバ側で対応するハンドラを実行させます。Responseはこれに対応する形で、成功時はresultキーに結果データを、失敗時はerrorキーにcode・message・dataを格納して返却します。
Notificationはidを持たないRequestで、レスポンスを返さない片方向の通知を表します。クライアントからサーバへ「これだけ伝えておきたい」というイベント通知や、サーバからクライアントへの進捗通知などに使われます。また、JSON-RPC 2.0は複数のRequest／Notificationを配列にまとめて一度に送信する「Batch」もサポートしており、ネットワーク往復回数を削減できます。これらの最小限な要素だけで構成されているため、実装が容易で、組み込み機器から大規模サービスまで幅広く採用されています。
JSON-RPCを利用する基本フロー
JSON-RPCを使ったやり取りは、サーバ側で公開するメソッドの仕様を定義するところから始まります。たとえばEthereumのノードでは「eth_getBalance」や「eth_blockNumber」といったメソッドが定義されており、クライアントは「method」: 「eth_blockNumber」、「params」: [] というJSONをHTTP POSTで送信します。
サーバはメソッド名に対応するハンドラを呼び出してビジネスロジックを実行し、成功時にはresultフィールドに値を入れて返却します。エラー時はerror.codeに-32600（不正なリクエスト）、-32601（メソッド未定義）、-32602（パラメータ不正）、-32603（内部エラー）といった仕様化された数値を入れ、必要に応じてdataフィールドに追加情報を載せます。クライアントはidをキーにレスポンスとリクエストを照合するため、複数の非同期リクエストを並行して扱う場合でも整合性を保てます。
JSON-RPC運用で押さえる注意点
JSON-RPCを長期的に運用するうえで重要なのは、バージョン管理と一意性の確保です。JSON-RPC 1.0と2.0ではフィールド構成が異なり、特にエラー表現や名前付きパラメータの扱いが大きく違うため、サーバとクライアントで使用バージョンを揃えなければなりません。また、idはレスポンスと紐づける唯一の手段なので、UUIDや単調増加カウンタを使って一意性を担保しておく必要があります。
エラー処理についても、仕様で定義済みの-32700番台のコードに加えて、アプリケーション独自のエラーコード体系を事前に定義しておくと、クライアント実装が共通化しやすくなります。Batchリクエストはネットワーク効率を高める一方で、サーバ側の処理負荷が突発的に増えるリスクがあるため、1リクエストあたりの最大数を制限し、超過時は400相当のエラーで拒否する設計が安全です。認証や暗号化はJSON-RPC自体には含まれていないため、HTTPSやWebSocket Secure上で動作させるなど、トランスポート層側で対策を実装します。
JSON-RPCとRESTの設計思想の違い
JSON-RPCとRESTはしばしば比較されますが、設計の出発点が大きく異なります。RESTはURIで「リソース」を識別し、HTTPメソッドで操作意図を表現する「リソース指向」のアーキテクチャです。一方JSON-RPCは関数呼び出しをそのままネットワーク越しに行う「RPC指向」で、URIは単一エンドポイントのまま、methodフィールドの値によって呼び出し先を切り替えます。
この違いから、JSON-RPCはユースケースが操作中心・ステートレス・大量の関数呼び出しを必要とするケースに向いています。Ethereumノード・Bitcoinノード・Language Server Protocol・Microsoft Debug Adapter Protocolなど、機能呼び出しが大量に並ぶシステムで採用されているのはこのためです。RESTのキャッシュ制御やHTTPセマンティクスは活用できなくなりますが、構造の単純さとBatch対応の恩恵が大きく、用途を見極めれば堅実な選択肢になります。
まとめ
JSON-RPCは、JSONとシンプルなメッセージ構造だけでRPCを実現する、軽量で実装しやすいプロトコルです。2.0で安定した仕様は、Ethereumに代表されるブロックチェーンノードやLanguage Server Protocolなど、現代的な領域でも基盤として活躍しています。RESTほどの汎用性はないものの、手続き呼び出し中心の用途では強力な選択肢となり、Batchやnotificationを活用して効率的なシステム間連携を実現できます。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント