REST — Web を制した標準
REST は HTTP メソッド（GET / POST / PUT / DELETE）とリソース指向の URL（/users/123/posts）に基づきます。あらゆる HTTP クライアントが対応し、CDN キャッシュも標準で効き、curl でデバッグでき、ブラウザがそのまま叩けます。代償として、新要件ごとにエンドポイントやクエリパラメータが増えがちで、クライアント要件が多様になると過剰取得／不足取得が起きやすくなります。
GraphQL — 必要なデータをクライアントが指定
GraphQL は単一エンドポイントを通じ、必要なデータ形状をクエリで明示します。過剰取得を防ぎ、フロントチームの独立性も高まります。代償として、URL ごとのキャッシュが効きにくく、クエリ深度制限や永続化クエリで攻撃耐性を担保する必要があり、サーバ側は任意の結合計画を担う責任を負います。
gRPC — スキーマ・コード生成・バイナリ高速
gRPC は Protocol Buffers でスキーマを定義し、HTTP/2 を使ってバイナリで送ります。ペイロードが小さく、ストリーミング対応で、多言語のコード生成が標準。サービス間通信の中では最も高速・型安全です。代償として、ブラウザから直接呼べず（gRPC-Web プロキシが必要）、人手でのデバッグが難しく、ツールが REST より特殊化されています。
スキーマ進化
REST は新エンドポイントやバージョン付き URL で進化させます。GraphQL はフィールドを追加（廃止は deprecate、削除しない）し、原則として後方互換に設計されています。gRPC は Protocol Buffers の明示的なフィールド番号で進化します。フィールド追加は安全ですが、番号の再利用は禁止です。どの方式も機能はしますが、チームの規律が求められる度合いが違います。
ブラウザサポート
- REST: HTML フォームも含めどこでも動作。
- GraphQL: JSON を POST できる全ブラウザで動作。
- gRPC: 直接は不可。ブラウザ向け HTTP/1.1 を native gRPC へ翻訳する gRPC-Web プロキシが必要。
キャッシュと CDN
ブラウザ・CDN キャッシュでは REST が圧倒的に強いです。GET リクエストは安定 URL と HTTP キャッシュヘッダで標準対応できます。GraphQL の POST は HTTP キャッシュをデフォルトで無効化します（回避策: 永続化クエリ、ハッシュ付き GET、Apollo 等のレスポンスキャッシュ）。gRPC は一般に公開 CDN を経由しません。
可観測性とデバッグ
REST はデバッグが最も容易で、アクセスログを見れば意味のある URL が並びます。GraphQL は操作の意図がクエリ本文に隠れるため、クエリ命名規約や GraphQL 対応 APM を導入する必要があります。gRPC はバイナリのため、OpenTelemetry や grpcurl などの専用トレースが必要です。
用途別の選び方
- 第三者が利用する公開 API: REST（クライアント対応が普遍的）。
- 形状が多様なフロントエンド（モバイル・デスクトップ・組み込み）: GraphQL。
- 大規模な社内マイクロサービス通信: gRPC。
- リアルタイム双方向ストリーム: gRPC（ストリーミング）または GraphQL Subscriptions。
- プロトタイプや単一クライアント: REST。