gRPCは効率的で高速かつ信頼性の高いRPC（Remote Procedure Call）フレームワークで、様々な場面で広く使用されている。マイクロサービスアーキテクチャにおいて、Apidogはサービス間の効率的な通信を実現する。大量のデータ転送が必要な場合、Apidogはストリーミング機能を活用してネットワークの遅延と帯域幅消費を削 減する。gRPC APIのデバッグ機能は現在ベータテスト段階だ。この機能を使用するにはApidogのバージョン2.3.0以上が必要。
新規gRPCプロジェクトの作成#
Apidogのホームページで「新規プロジェクト」ボタンをクリックし、「gRPCプロジェクト（Beta）」を選択する。Protoのインポート#
gRPCはAPI-Firstアプローチを採用しており、開発前に .proto ファイルでサービス、メソッド、メッセージを定義する必要がある。そのため、ApidogでgRPC APIをデバッグする前に、API定義となる .proto ファイルをインポートする必要がある。初回インポート#
現在、.proto ファイルのインポートには2つの方法がある：選択した .proto ファイルは1つのProtoとしてインポートされ、サービスはサービスとして 、rpcはメソッドとしてインポートされる。選択した .proto ファイルが他の .proto ファイルに依存している場合、依存ディレクトリを手動で追加する必要がある。選択した .proto ファイルが依存する他の .proto ファイルのサービスも、そのパッケージが選択した .proto ファイルと同じパッケージに属している場合、同じProtoにインポートされる。再インポート#
インポートした .proto ファイルに変更がある場合、Apidogで再インポートできる：Protoを右クリックし、「再インポート」ボタンをクリックする。呼び出し方法#
.proto ファイルでgRPCメソッドを定義する際、Apidogは4つのタイプをサポートしている：Server Streaming: サーバーサイドストリーミング
Client Streaming: クライアントサイドストリーミング
Bidirectional Streaming: 双方向ストリーミング
Unary呼び出し#
Unary呼び出しはHTTPリクエストに似ている。アドレスバーにURLを入力し、メッセージタブでJSON形式のメッセージ内容を入力して、「呼び出し」ボタンをクリックすると、Unary呼び出しが開始される。また、認証やその他の複雑なシナリオに対応するため、MetadataとAuth情報を手動で入力することもできる。ストリーミング呼び出し#
ストリーミング呼び出しはWebSocket接続に似ている。呼び出しを開始後、メッセージタブでメッセージを作成して送信できる。サーバーストリーミング、クライアントストリーミング、双方向ストリーミングがストリーミング呼び出しタイプに含まれる。Apidogはタイムラインビューを提供し、呼び出し状態、送信メッセージ、受信メッセージを時系列で一元的に表示する。メッセージをクリックすると、メッセージの詳細を簡単に確認できる。高度な使い方#
動的な値の自動生成#
Apidogは .proto ファイルの内容を認識でき、「自動生成」ボタンをクリックしてメッセージボディを生成できる。より柔軟な動的データが必要な場合は、「動的な値」機能を使って式を設定・生成できる。変数の使用#
gRPCメッセージやMetadataでApidogの変数を使用できる。詳細な手順については、「環境変数のタイプ」のドキュメントを参照。TLSの有効化#
gRPC APIはTLSを通じてセキュアな接続を確立できる。Apidogでは、URLの前にあるプロトコル選択をクリックしてTLSの状態を素早く切り替えることができる。また、URLで grpcs:// を使用してTLS 接続を有効にすることもできる。逆に、grpc:// はTLSが無効であることを示す。サーバーアドレスと環境の管理#
URLアドレスバーの右側にあるプラスアイコンをクリックして、現在使用中のサーバーアドレスを環境に追加できる。その後、右上で環境とサーバーアドレスを選択し、URLアドレスバーで「デフォルトに従う」を選択すると、すべてのメソッドのデバッグに統一されたサーバーアドレスを使用できる。Protoファイルとパラメータの表示#
Protoファイルの内容表示#
Apidogで左側のディレクトリツリーのProtoをクリックすると、.proto ファイルの生の内容を表示できる。リクエストとレスポンスのパラメータ表示#
gRPCはProtoBufをシリアライゼーション形式として使用しており、メッセージの送受信時にはすべてのメッセージがProtoBuf形式で転送される。他のテキストベースのシリアライゼーション形式（JSON、XML）と異なり、ProtoBufはバイナリ形式で人間による読み書きには適していない。そのため、ApidogでgRPC APIを呼び出す際、すべてのメッセージはJSON形式で記述・表示される。API情報ページでJSON形式で表現されたリクエストとレスポンスのパラメータを確認できる。ProtoBufとJSONのデータ型には以下の表のような対応関係がある：| ProtoBuf 3 | JSON | JSONの例 |
|---|
| message | object | {"fooBar": v, "g": null, …} |
| enum | string | "FOO_BAR" |
| map<K,V> | object | {"k": v, …} |
| repeated V | array | [v, …] |
| bool | boolean | true, false |
| string | string | "Hello World!" |
| bytes | base64 string | "YWJjMTIzIT8kKiYoKSctPUB+" |
| int32, fixed32, uint32 | number | 1, -10, 0 |
| int64, fixed64, uint64 | string | "1", "-10" |
| float, double | number | 1.1, -10.0, 0, "NaN", "Infinity" |
デバッグ情報の保存#
デバッグが完了したら、「保存」ボタンをクリックして、現在のメ ソッドのサーバーURL、メッセージ、Metadataなどを保存し、他のチームメンバーがデバッグできるようにする。 
