protobuf (Protocol Buffers) とはGoogleによって開発されたデータ交換用のフォーマットとして知られています。現在、protobufはgRPC通信でよく使われています。本文では、protobufの基本情報を紹介した上、最近注目されていたgRPC(Remote Procedure Call)という技術をも皆さんに解説していこうと思います。
また、Apidogは個人利用永久無料なツールなので、必要な方は下記のボタンから無料で取得しましょう。
protobufとは
protobuf (Protocol Buffers) とは、データ構造のシリアライズおよびデシリアライズを効率的に行うための方法です。
主な特徴は以下の通りです:
- Googleによって開発されたデータ交換用のフォーマット
- 構造化されたデータをシリアライズするための手段を提供
- 言語およびプラットフォームに依存しない
- 拡張性が高い
- データサイズが小さく高速にエンコード/デコードできる
protobufはインターフェース記述言語(IDL)を使用してデータ構造を定義します。これに基づいて特定のプログラミング言語のためのソースコードが自動生成されます。この生成されたコードを使用してデータのシリアライズとデシリアライズが行われます。
様々なプログラミング言語(C++、Java、Python等)をサポートしているため、異なる言語間でのデータ交換にprotobufがよく利用されています。分散システム間の通信においても効率的である点から、最近ではWeb APIなどでも採用されつつあります。
protobufとgRPCの関係を知る
protobufとgRPCは密接な関係があります。protobufはデータシリアライズのためのフォーマットとして、構造化データを効率的にエンコードし、言語・プラットフォーム間で転送できるようにすることを目的としています。その一方、gRPCはリモートプロシージャコール(RPC)を実現するためのフレームワークです。サーバとクライアント間での procedure 型の通信を可能にします。
gRPCでは通信を行うインターフェースを .proto ファイルで定義します。gRPCはこのprotoファイルで定義されたデータ構造を利用して、サーバとクライアント間の通信を実現します。
つまり、protobufでEncoding/Decodingの部分を担い、gRPCがそのエンコードされたデータをやり取りする通信インフラストラクチャを提供する、という役割分担の関係です。
このため、gRPCを利用する際にはほぼ必ずprotobufが利用されます。APIの定義とデータ転送をprotobufとgRPCがシームレスに分担することで、効率的で拡張性の高いシステムを構築できます。
gRPCとREST VS. protobufとJson
前述のようにgRPC APIは、protobuf(protoファイル)で定義していて、主流のREST APIは、主にJSONによって定義されています。そこで、この部分では、gRPCとRESTful APIの主な違いを比較した上、両者が利用するファイルの種類であるprotobufとJSONをも比較していこうと思います。
gRPCとRESTとの比較
まずは、gRPCとRESTの比較です。gRPCとRESTとの違いというと、主に利用するプロトコル、通信方式、インターフェース、データフォーマット、パフォーマンスなどの側面から比較できます。
プロトコル
- gRPC: HTTP/2上で動作するプロトコル
- REST: HTTP上で動作する
通信方式
- gRPC: リモートプロシージャコール(RPC)ベース
- REST: リソース中心のアーキテクチャ
インターフェース
- gRPC: .protoファイルにて定義
- REST: OpenAPIなどで定義が可能
データフォーマット
- gRPC: バイナリ形式のProtobuf
- REST: JSONやXMLなど
パフォーマンス
- gRPC: ストリーミングやバイナリデータため高速
- REST: テキストフォーマットのオーバーヘッドがある
クライアント生成
- gRPC: インターフェースからクライアントコードを生成
- REST: 明示的なコード生成機能なし
このように、アーキテクチャや実装技術が異なることから、用途に応じてgRPC、RESTそれぞれの特徴を生かすことが大切です。
protobufとJSONの違い
また、gRPCとRESTを定義するファイルのフォーマットとして、protobufとJSONを比較する必要もあると思いますので、次は両者の違いを紹介します。protobufとJSONの主な違いは以下の通りです。
フォーマット
- protobuf: バイナリ形式
- JSON: テキスト形式
データサイズ
- protobuf: 小さい
- JSON: 大きい
言語依存性
- protobuf: 言語依存しない
- JSON: 言語に多少依存する
流通性
- protobuf: 事前にスキーマの共有が必要
- JSON: スキーマがなくても解釈可能
可読性
- protobuf: 人間が読みづらい
- JSON: 人間可読性が高い
つまり、protobufのほうがエフィシエントで構造化に適していますが、JSONは自由度と可読性に優れています。
protobuf(protoファイル)の書き方
ProtobufはマイクロサービスアーキテクチャやgRPCでの利用が最も一般的ですが、他にも様々な場面で活用されています。機械学習、組み込みシステム、金融系ストリーミング、モバイルアプリなど、データ転送効率と柔軟なモデリングが必要とされる場面での利用が増えています。でも、どのようなところでprotobufを利用しようとしても、protobuf(protoファイル)の書き方は全く同じですので、次は、protobuf(protoファイル)のサンプルと一緒に、その書き方を皆さんに解説していこうと思います。
それでは、protobufを使用したシリアライズとデシリアライズの完全なサンプルコードをC++で示します。
まず、Personメッセージを定義したperson.protoファイルが以下のようにあります。
syntax = "proto3";
message Person {
string name = 1;
int32 id = 2;
string email = 3;
}
次にこのprotoファイルからC++クラスを生成します。
protoc -I=. --cpp_out=. person.proto
これでperson.pb.hとperson.pb.ccファイルが生成されます。
main.cppではこの生成されたクラスを利用してシリアライズとデシリアライズを行います。
#include <iostream>
#include "person.pb.h"
int main() {
// Personオブジェクトを作成
tutorial::Person person;
person.set_name("John Doe");
person.set_id(1234);
person.set_email("john@example.com");
// シリアライズ
std::string serialized;
person.SerializeToString(&serialized);
// デシリアライズ
tutorial::Person new_person;
new_person.ParseFromString(serialized);
// データの出力
std::cout << new_person.name() << std::endl;
std::cout << new_person.id() << std::endl;
std::cout << new_person.email() << std::endl;
return 0;
}
これでprotobufによるデータのシリアライズとデシリアライズのサンプルが完成です。必要に応じてさらにフィールドを追加したり、複雑なメッセージ階層を定義することもできます。
Apidog:protobufに対応、gRPCの作成とテストが簡単に
ApidogはAPIの設計、開発、デバッグ、テスト、モックなどの機能をも一体化した包括的なAPI管理プラットフォームです。Apidogは、protobufとgRPC APIにも完璧に対応できますので、protobufとgRPC APIを扱う必要がある場合は、非常に役に立つツールになります。
それでは、次は、Apidogを使用してprotoファイルをインポートして、gRPC APIを簡単に取り扱う操作手順を皆さんに紹介します。
gRPCプロジェクトの作成
Apidogのホームページで「新しいプロジェクト」ボタンをクリックして、gRPCプロジェクトを新規作成することができます。

Protoのインポート
gRPCは、API中心のテクノロジーなので、開発に移る前に、.protoファイルを通じて、サービス、方法およびメッセージを定義する必要があります。そこで、Apidogを使用して、gRPCの単体テストを行う前に、APIの定義として.protoファイルをインポートする必要があります。
初のインポート
現在、.protoファイルをインポートするには、2つの方式が利用できます。
- ローカルファイル
- .protoファイルのURL

- .protoファイルは1つのprotoとしてインポートされ、その中のserviceはサービスになり、rpcは方法になります。
- 当該.protoファイルは他の.protoファイルに依存している場合、手動で依存関係を追加する必要もあります。
- .protoファイルは他の.protoファイル内のserviceに依存している場合、その
package
は、選択の.proto
ファイルのpackage
と同じな場合、同じなProto
にインポートされます。
再インポート
インポートした.protoファイルが変更された場合、Apidogでそれを再インポートすることができます。Protoを右クリックして、「再インポート」をクリックします。

実行の方法
.protoファイルを使用して、 gRPCの方法を定義する場合、以下のように4つの方法が利用できます。
- Unary:一元実行
- Server Streaming:サーバーのストリーミング
- Client Streming:クライアントストリーミング
- Bidirectional Streaming:双方向ストリーミング
一元実行
一元の実行は、HTTPリクエストに似ています。アドレスバーにURLを入力して、「Message」タブでJSONフォーマットでメッセージを入力した後、「実行」ボタンをクリックします。

ストリーミング方式
ストリーミング方式は、Websocketの接続に似ています。「Message」タブでJSONフォーマットでメッセージを入力して送信できます。サーバーストリーミング、クライアントストリーミング、双方向ストリーミングは、全てストリーミング方式に属しています。
Apidogは、タイムラインを備えており、時間順に実行の状態、送受信のメッセージを表示します。メッセージをクリックすると、メッセージの詳細を見ることができるので非常に便利です。

高度なオプション
動的値の自動生成
Apidog は、.protoファイルの内容を識別できるので、「自動生成」をクリックして、送信メッセージを自動的に生成できます。また、動的値ボタンをクリックして、動的値を利用することもできます。

変数の使用
gRPCのメッセージとMetadataで、Apidogの変数を利用できます。

TLSをオンにする
gRPC APIは、TLSを通じて安全に接続することができます。
Apidogを使用すると、URLの前のプロトコルをクリックして、TLSの状態を快適に切り替えます。
また、URLに「grpcs://」を使用すると、ApidogはTLSをオンにします。それに対して、「grpc://」の場合は、TLSは無効になります。

サーバーのURLと環境の管理
URLアドレスの右側にある「+」アイコンをクリックして、現在利用中のサーバーURLを環境に追加することができます。

そして、右上で環境やサーバーのURLを選択し、URLの設定を「デフォルトを継承」にすることで、すべての方法も同じなURLで単体テストを行うようになります。

ProtoファイルとAPIのパラメータを確認
Protoファイルの内容を確認
Apidogの左側にメニューツリーのProtoをクリックすると、Protoファイルのオリジナル内容を確認できます。

リクエストとレスポンスのパラメータを確認
gRPCはシーケンス化フォーマットとしてProtoBufを使用しています。これは、メッセージの送受信の際に、各メッセージがProtoBufフォーマットで転送されることを意味しています。ProtoBufは、他のテキストに基づくフォーマット(JSON,XML)とは異なり、バイナリ形式なので、人間がそれを読み書きしたりすることが難しくなります。
そこで、ApidogでgRPC APIを呼び出す際には、すべてのメッセージをJSONフォーマットで作成したり、表示したりしています。
APIの情報ページで、JSONフォーマットで表示されているレスポンスとパラメータの情報を確認できます。

ApidogのprotobufとJSONとのマッピング(変換)
protobufとJSONも互換性があり、相互変換することが可能です。Apidogでは、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 | true, false | true, false |
string | array | "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" |
まとめ
本記事では、protobufおよびgRPCの概要から実践的な活用法までをApidogを中心に解説しました。Apidogはprotobuf対応のAPI管理プラットフォームで、protoファイルから容易にAPI定義を取り込み、gRPCのデバッグやテストが手軽にできます。
- protoファイルのインポートや再インポートが簡単
- 一元実行からストリーミングまで全メソッド型に対応
- 変数機能や動的値生成で柔軟なテストを可能に
- 開発効率が大きく向上する
他にもTLS通信やテスト環境管理など、Apidogならではの機能が豊富で、protobufやgRPCでの開発を強力にサポートします。gRPCやprotoファイルの扱いに悩んでいる方は、ぜひApidogを活用して開発効率を飛躍的に高めましょう。