Skip to content
Latchkey

gRPC vs REST: どちらのAPIスタイルを選ぶか

gRPCはコード生成を備えたHTTP/2上のcontract-firstなバイナリRPC。RESTはどこでも使え、ブラウザに優しいHTTP上のリソース指向JSONです。

gRPCはProtocol BuffersとHTTP/2を用いて、コンパクトで高速な強く型付けされた呼び出しを行い、streamingと生成されたクライアントを備え、内部マイクロサービスに理想的です。RESTはHTTP動詞とJSONを用い、普遍的にサポートされ、curlでのデバッグが容易で、ブラウザでネイティブに動作します。gRPCはパフォーマンスと型付き契約を、RESTはリーチ、シンプルさ、ブラウザ互換性を重視します。

gRPCREST
PayloadProtobuf(バイナリ)JSON(テキスト)
トランスポートHTTP/2HTTP/1.1+
契約強い(.proto)OpenAPI(オプション)
ブラウザgRPC-Webが必要ネイティブ
最適な用途内部マイクロサービス公開/ブラウザ向けAPI

ユースケースとパフォーマンス

gRPCは、低レイテンシ、streaming、言語横断で生成された型付きクライアントを必要とする内部のサービス間呼び出しで優れています。RESTは、公開API、ブラウザクライアント、そして人間が読めるpayloadと広いtoolingの恩恵を受けるあらゆるものに優れています。チームは外部にRESTを公開し、内部でgRPCを使うことがよくあります。

CIにおいて

gRPCのpipelineはprotoc/bufでcodegenを実行し、生成されたコードが最新かを確認します。RESTのpipelineはOpenAPIを検証し、契約テストを実行します。どちらもマネージドrunnerで動作し、より高速なrunnerはcodegenと契約テストのステップを短縮します。

結論

内部の高性能で強く型付けされたマイクロサービス呼び出しならgRPC。公開向け、ブラウザ向け、人間が読めて最も広いtoolingを持つAPIならREST。よくあるアーキテクチャは、エッジにRESTを、内部サービス間にgRPCを使う構成です。

関連ガイド