【図解で比較】gRPC vs REST — API通信方式の違いを徹底解説

一番大きな違いはデータのやり取りの仕方だね。RESTはJSON（テキスト形式）でデータを送るけど、gRPCはProtocol Buffers（バイナリ形式）を使うんだ。バイナリだから人間には読めないけど、コンピュータにとっては軽くて速いんだよ。

いい質問だね。たしかにRESTのJSONはブラウザやcurlで簡単に中身を確認できるけど、gRPCのバイナリはそのままでは読めない。ただ、gRPCには専用のデバッグツール（grpcurlやBloomRPC）があるし、Protocol Buffersの定義ファイル（.protoファイル）を見れば構造がわかるから、慣れれば困らないよ。

APIの「設計図」みたいなものだよ。どんなデータをやり取りするか、どんなメソッドがあるかを.protoファイルに定義しておくと、そこからサーバーとクライアントのコードが自動生成されるんだ。RESTだとOpenAPIのドキュメントを書いて、そこからコードを生成することもあるけど、gRPCはコード生成が標準フローに組み込まれているのが大きな特徴だね。

あるよ。RESTは一般的にHTTP/1.1を使うけど、gRPCはHTTP/2が前提なんだ。HTTP/2だと1つの接続で複数のリクエストを同時に送れる「多重化」ができるし、ヘッダーも圧縮されるから通信効率がかなり良いんだよ。

使えるよ。ただRESTでHTTP/2を使っても、JSONのテキスト解析のオーバーヘッドは残るんだ。gRPCはバイナリ＋HTTP/2＋ヘッダー圧縮の組み合わせで、全体としてRESTより2〜10倍速いと言われているよ。特にマイクロサービス間の通信のように大量のAPIコールが飛び交う場面では、この差がかなり効いてくるんだ。

RESTは基本的に「リクエストを送って、レスポンスが返ってくる」の1往復で完結するよね。gRPCにはそれに加えて3つのストリーミングパターンがあるんだ。サーバーが連続でデータを送る「Server streaming」、クライアントが連続で送る「Client streaming」、そして双方向にリアルタイムでやり取りする「Bidirectional streaming」。チャットやリアルタイム監視のような用途にはとても強いよ。

実はそこがgRPCの弱点なんだ。ブラウザのJavaScriptからは直接gRPCを呼べない。gRPC-Webというプロキシ経由の仕組みはあるけど、双方向ストリーミングが使えないなど制約が多い。だからWebフロントエンド → バックエンドはRESTやGraphQLを使い、バックエンドのマイクロサービス間はgRPCを使う、という使い分けが多いんだよ。

シンプルに言うと、外部公開APIやWebアプリのバックエンドにはRESTが向いている。学習コストが低くて、ブラウザから直接叩けるし、エコシステムも成熟しているからね。一方で、マイクロサービス間の内部通信、リアルタイム性が必要なシステム、モバイルアプリのように帯域を節約したい場面ではgRPCが強い。GoogleやNetflixのような大規模サービスでは、内部通信のほぼすべてをgRPCに移行しているよ。

意外と知られていないのが、gRPCのリフレクションAPIだね。サーバーが自分自身のAPI定義を返す仕組みで、.protoファイルがなくてもクライアントがAPIの構造を動的に発見できるんだ。それから、gRPCのデッドライン伝播という機能も重要だよ。サービスAがサービスBを呼び、BがCを呼ぶような連鎖で、最初に設定したタイムアウトが自動的に下流のサービスに伝わる。これがあるおかげで、マイクロサービスのタイムアウト管理が劇的に楽になるんだ。RESTでこれをやろうとすると、自前で実装しなきゃいけないんだよ。

そうなんだ。あとProtocol Buffersには後方互換性のルールがしっかりあって、フィールドの追加は既存クライアントを壊さないし、フィールド番号を使って管理するから、JSONのキー名変更のような事故が起きにくい設計になっている。大規模チームでAPIを長期運用するときには、この堅牢さがとても効いてくるんだよ。