JSON-RPCとは？

JSON: 何かと仕組み?

JSONは高速なデータ転送に適した軽量なメッセージ形式です。そのため、今日の環境で広く利用されています。

JSON (JavaScript Object Notation)は、処理しやすい形になるまでデータを分割します。基本的にJavaScriptベースなため、データ要素を確認する際、多くの文字列、null文字、オブジェクト、Boolean変数が見受けられます。  

複雑に配置されたデータを扱いやすい構造に分割することで、多くのプログラミング言語で簡単に処理できるようになります。このため、JSONは言語に依存しないリソースです。2000年にDouglas Crockfordによって生み出され、Webアプリやサーバ間の通信を促進します。

JSON-RPCの概要

簡単に言えば、JSON-RPCはJSONに続く、グローバルに認識されたリモートプロシージャコール用のプロトコルです。開発現場では、様々なデータ構造を用いたタスク定義に役立ちます。比較的新しいプロトコルであり、用途は限定的です。 

コマンドセット、柔軟性、導入シナリオはいずれも制約があります。しかし、シンプルで迅速な開発が求められる場合、開発者にとって最適な選択肢です。こうした制約がシンプルなケースでは有利に働き、RESTからJSON-RPCへの移行が促されることもあります。さらに以下の点が挙げられます:

• ネットワーク上でのデータ処理に関する制約を定めている。
• 軽量な構造と高速な処理により、Ethereumノードとのデータ転送に適している。
• 伝送手段に依存しないため、ソケットやHTTPを利用した連携が可能。
• Blockchainを活用するEthereumベースのソリューション開発に最適である。

現在、JSON-RPCには2つの仕様、JSON-RPC 1.0とJSON-RPC 2.0が提供されています。

• JSON-RPC 1.0は多くの面で実用性に欠け、特に名前付きパラメータやエラーメッセージの説明がなかったため、予想以上の問題を引き起こしました。主にピアツーピアの通信方式でした。
• 更新されたJSON-RPC 2.0は大幅に進化し、前バージョンの欠点を解消しました。v1.0はクライアント―サーバ方式に置き換えられ、伝送手段への依存も排除されました。 
  

もちろん、名前付きパラメータが追加され、フィールドも整理されました。通知にはIDがなく、結果またはエラーのみがレスポンスとして送信されます。更新版では、詳細なエラー情報を含む拡張機能も追加されています。 

JSON-RPCの使い方

このプロトコルの基本的な機能は、クライアントからのリクエストをJSON-RPC対応のサーバへ送ることです。ここでいうクライアントとは、遠隔システムからの統一的なメソッドリクエストを受信するために配置されたソフトウェアを指します。  

入力されたパラメータは、配列またはオブジェクト形式で遠隔システムに送られます。使用されるJSON-RPCのバージョンに応じて、リモートシステムは様々なデータをリクエスト元に返します。

JSON-RPCを用いたすべてのウェブ転送は、JSONのみで統一・シリアライズされます。JSON-RPCのリクエストは、リモートメソッドへの呼び出しを意味し、次の3要素から成ります:

1. Method: メソッド呼び出し時に求められる文字列を指します。内部RPC呼び出し用に「rpc」接頭辞の予約済み名が存在するため、これらのメソッド名は自由に使用できません。
2. Params: オブジェクトまたは配列形式で、引き渡すパラメータの値を含むJSON-RPCの第2要素です。全ての呼び出しで必ず使用されるわけではありません。 
3. ID: レスポンスとリクエストの対応を保つために用いられる整数または文字列です。該当するレスポンスがない場合、このIDは自動的に削除されます。  

JSON-RPCのリクエストでは、受信側が各リクエストに対して必ず検証済みのレスポンスを返し、さらに以下の3要素を含みます:

1. Result: 呼び出されたメソッドが返すデータを含む最も重要な部分です。エラーが発生した場合は存在しません。
2. Error: プロセス呼び出し時に問題が起これば現れ、コードとメッセージがその主要な要素となります。
3. レスポンスID: どのリクエストに対するレスポンスかを示します。レスポンスが不要な場合、JSON-RPCはIDのないリクエスト、つまり通知を使用します。v1では通知IDがnullとして送信され、v2.0では完全に省略されます。

JSON-RPCの利点

JSON-RPCは創意に富んだプロトコルで、次のような多くの利点があります。

シンプルな扱いやすさ

RESTに比べ、JSON-RPCは非常にシンプルです。人間にも機械にも理解しやすく、混乱を招くコマンドやデータセットは存在しません。これにより初心者の開発者にも最適な選択肢となります。Unicodeプロトコルとして、短い共通行を持ち、名前付きフレーズや特定キーワードを含むデータの処理も可能です。こうした特性により、清潔で扱いやすい選択肢となっています。

迅速な開発時間

JSON-RPCでは複雑な検討がほとんど不要で、リソースも分かりやすく提供されます。これにより、アプリ開発にかかる時間と市場投入までの期間が短縮され、時間に制約がある場合に最も好まれます。

より良い情報交換

JSON-RPCは通知や複数呼び出しの処理により、適時で迅速かつ確実な情報交換を実現します。サーバやクライアントのレスポンスを待たずに次の処理へ進むため、リクエストがあれば確実に目的地へ届けられます。どんなに複雑なソフトウェア部品が絡んでいても、適切な情報交換が行われます。

向上したAPI性能

JSON-RPCを利用すればプロトコルに依存しないAPIを構築でき、HTTPをTCPに置き換えオーバーヘッドを削減することで、API性能が向上します。

分かりやすい結果

JSON-RPCは自己説明的なレスポンス結果を提供し、容易に理解・処理できます。バッチリクエストの実行、HTTPボディの解説、パラメータの引き渡しなども非常に簡単です。

改善された送信

JSON-RPCはXMPP、WebSockets、SFTP、SSH、SCPなどのプラットフォームをサポートしており、送信に適したツールです。この分離により、迅速で使いやすく、デバッグが容易なAPIの開発が促進されます。さらに、リクエスト内容は送信プロセスから完全に独立して扱われるため、エラーやデータ、警告はリクエストペイロードとして提供されます。

API開発において選ぶべきは - RESTかJSON-RPCか？ 

APIリソースが豊富であることは多面的に良い点ですが、その一方で選択に迷う開発者もいます。以下では、これら2つのプロトコルの主な機能を説明し、開発者の判断の一助とします。 

開発者が初心者で、限られたリソースで開発を行う場合、JSON-RPCが適しています。リソースが限られているにもかかわらず、十分な機能を発揮します。また、分散台帳技術を利用する開発では、RESTなど他のプロトコルではなく、JSON-RPCが唯一有力な選択肢となります。どのプロトコルも、JSON-RPCのような展開には対応できません。

分散台帳システムを必要とするアプリ開発では、プロトコルに依存しないAPIが求められますが、JSON-RPCはそれを実現します。あらゆるプロトコルを利用して相互連携が可能なAPIの開発ができます。  

JSON-RPCがRESTに勝る点として、RESTは動詞が限られており、操作実行時に問題が生じやすいことが挙げられます。REST利用時は詳細なHTTPメソッドの指定が必要で、時間がかかります。また、RESTではCRUD操作のみが可能です。JSON-RPCがより好まれる理由です。

しかし、JSON-RPCは常に有利というわけではなく、密結合が大きな課題となります。クライアントがサービス実装に強く結び付けられるため、実装変更が困難になり、不具合が生じる可能性があります。

RESTは多くの面でシンプルです。例えば、RESTベースのAPIはステートレスで設計が容易であり、HTTPに準拠し多くのHTTPライブラリが利用可能です。柔軟性に富み、CRUD操作にも適しています。

どちらのプロトコルにも長所と短所があるため、主たる開発目標に基づいて判断する必要があります。例えば、高い計算性能が求められる場合はJSON-RPCが適しています。  

アプリ開発がプロトコルに依存せず、解りやすいインターフェースを求める場合はRESTを推奨します。さらに、APIセキュリティにも留意してください。

JSON-RPC vs GraphQL vs gRPC

JSON-RPCの2大有名な対抗プロトコルは、GraphQLとgRPCです。GraphQLは必要なリクエストデータのみを正確に取得できる非常に柔軟なシステムで、クライアント主導である点が特徴です。サーバの役割はほとんどなく、リクエストデータの取得はクライアント側が主に決定します。

カテゴリで言えば、GraphQLはクエリ言語に分類され、JSON-RPCはリモートプロシージャコールに属します。

一方、gRPCは性能重視で軽量なプロトコルであり、RPCの改良版です。JSON-RPCではサーバとクライアント間でリクエストデータのやり取りが行われ、特定のアーキテクチャは関与しませんが、gRPCでは事前に定められたスキーマに基づいてリクエストが処理され、どのエコシステムでも動作可能です。

JSON-RPCはMQTT、Python、Kallitheaとの連携が可能な一方、.NET、JavaScript、C++、SwiftなどはgRPCに関連しています。

これらすべてのリソースの共通点は、オープンソースであり、手軽に利用できる点です。