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はリーチ、シンプルさ、ブラウザ互換性を重視します。
| gRPC | REST | |
|---|---|---|
| Payload | Protobuf(バイナリ) | JSON(テキスト) |
| トランスポート | HTTP/2 | HTTP/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を使う構成です。
関連ガイド
REST vs GraphQL: Which API Paradigm?REST vs GraphQL: fixed resource endpoints vs a single flexible query language. Over-fetching, caching, toolin…
Protobuf vs JSON: Binary or Human-Readable?Protocol Buffers vs JSON: compact, schema-driven binary serialization vs ubiquitous human-readable text. Size…
WebSocket vs SSE: Which Realtime Transport?WebSocket vs Server-Sent Events: full-duplex bidirectional messaging vs simple one-way server push over HTTP.…