REST vs GraphQL vs gRPC: 2026 年の意思決定フレームワーク

あなたのチームが新しいサービスを開始します。 誰かが「GraphQL を使用するべきですか?」という Slack スレッドを開きます。 他の人が返信する gRPC ベンチマークへのリンク付き。 スレッドは 3 つの陣営に分かれます。 2時間経っても決断は出ず。

問題は情報不足ではありません。 問題は基準がないことだ。 REST、GraphQL、gRPC それぞれ 異なる形の問題を解決します。 間違ったものを選択すると、何年にもわたってリクエストごとに税金を支払うことになります。 正しいものを選択すると、建築物が背景に消えていきます。

このガイドでは、「状況に応じて」ではなく、具体的な意思決定の枠組みを提供します。 各プロトコルは特定の 成功するユースケース、実行できるコード例、およびドロップできる比較表 デザインドキュメント。

30秒のフレームワーク

まずは 3 つの質問から始めましょう。

1. この API を呼び出すのは誰ですか? 外部の開発者、自社のフロントエンド クライアント、それとも内部サービスですか?
2. クライアントはいくつのデータ形状を必要としますか? 1 つの固定された形状ですか、それとも多数のバリエーションですか?
3. キャッシュ可能性、クエリの柔軟性、それとも生のスループットのうち、どれがより重要ですか?

答えはプロトコルに直接マッピングされます。

• 休む 視聴者が外部であり、データの形式が固定されており、キャッシュが重要である場合に優先されます。
• グラフQL 複数のクライアントが同じデータ グラフの異なるスライスを必要とする場合に最適です。
• gRPC 内部サービスが相互に通信し、人間の可読性よりもスループットが重要な場合に成功します。

コードと同じロジックは次のとおりです。

REST: 普遍的なデフォルト

REST は、操作を HTTP 動詞にマッピングし、リソースを URL にマッピングします。 すべてのプログラミング言語には HTTP クライアントがあります。 すべての CDN はキャッシュ ヘッダーを理解します。 すべての開発者が使用している curl。

REST は、データ形状を制御し、クライアントが安定性を期待するパブリック API に最適な選択肢です。 文書化されたエンドポイント。 botoi の 150 以上の API エンドポイントはすべて REST を使用します。 DNS ルックアップは次のとおりです。

応答：

リクエストは単一の POST です。 応答はフラットな JSON オブジェクトです。 カールしてパイプしてテストできます を通して jq、または任意の言語から呼び出します。 fetch。 コンパイルするスキーマ ファイルがありません。 学習するクエリ言語やコード生成手順は必要ありません。

RESTが輝く場所

• 公開開発者 API。 サードパーティ開発者は REST を期待しています。 導入コストはゼロです。
• キャッシュ可能なリソース。 HTTP キャッシュは、ブラウザー、CDN、リバース プロキシなど、あらゆるレイヤーで機能します。 あ GET /users/123 適切なキャッシュ ヘッダーを含む応答は、繰り返しのリクエストでは費用がかかりません。
• Webhook の統合。 Webhook は HTTP POST リクエストです。 RESTはメンタルモデルに適合します。
• 単純な CRUD 操作。 各エンドポイントが 1 つの入力シェイプと 1 つの出力シェイプを使用して 1 つの処理を実行する場合、REST はオーバーヘッドを追加しません。

REST が不十分な点

• 過剰取得。 ユーザー プロファイルから 3 つのフィールドを必要とするモバイル アプリでは、依然として 40 フィールド全体のオブジェクトがダウンロードされます。
• アンダーフェッチ。 ユーザー、そのチーム、および最近のアクティビティを表示するダッシュボードは、3 回の連続した HTTP 呼び出しを行います。 レイテンシーが加算されます。
• 組み込みのスキーマ進化はありません。 URL をバージョン管理します (/v1/、 /v2/) またはフィールドを追加して、クライアントが不明なキーを無視することを望みます。

GraphQL: クライアント主導のクエリ

GraphQL を使用すると、クライアントは 1 つのリクエストで必要なフィールドを正確に指定できます。 サーバーが公開する 型付きスキーマ。 クライアントはそのスキーマに対してクエリを作成し、一致するように整形された応答を返します。

GitHub のパブリック API はこれをよく示しています。 1 つのクエリでユーザー名と上位 3 つのリポジトリを取得します 星の数と第一言語も表示されます。 REST では、これには少なくとも 2 回の呼び出しが必要になります。

応答：

クライアントが求めたのは、 name、 stargazerCount、 そして primaryLanguage。 サーバーはまさにそれらのフィールドを返しました。 余分なデータは転送されません。 2回目のリクエストはありません。

GraphQL が輝く場所

• モバイルアプリ。 帯域幅には制限があります。 ペイロードのサイズが重要です。 GraphQL は、すべての画面でのオーバーフェッチを排除します。
• ダッシュボードと集計ビュー。 単一のクエリで、ユーザー、注文、在庫から 1 往復でデータを取得できます。
• フロントエンドの迅速なイテレーション。 フロントエンド チームは、バックエンド チームが新しいエンドポイントを構築するのを待たずにクエリを変更します。
• 強力なタイピング。 スキーマは契約です。 GraphQL Code Generator などのコード生成ツールは、そこから TypeScript 型を生成します。

GraphQL が不十分な点

• キャッシング。 すべてのクエリは次への POST です /graphql。 CDN またはブラウザー レベルでの HTTP キャッシュは、永続化クエリ レイヤーまたは GET ベースのクエリがなければ機能しません。
• セキュリティ面。 クライアントは、深くネストされたデータを結合する負荷の高いクエリを作成できます。 悪用を防ぐには、クエリのコスト分析と深さの制限が必要です。
• 学習曲線。 開発者は、クエリ言語、スキーマ設計、リゾルバー、および DataLoader パターンを学ぶ必要があります。 立ち上がり時間は REST よりも長くなります。
• N+1 クエリ。 単純なリゾルバー パターンは、リスト内の項目ごとに 1 つのデータベース クエリをトリガーします。 DataLoader のバッチ処理によりこの問題は解決されますが、自分で構築する必要があります。

gRPC: 内部速度

gRPC は、シリアル化にプロトコル バッファーを使用し、トランスポートに HTTP/2 を使用します。 サービスを定義するのはあなたです で契約する .proto ファイルを作成し、クライアントおよびサーバー コードを生成し、タイプ セーフな RPC 呼び出しを取得します。 バイナリペイロードを使用します。

この定義から、 protoc Go、Java でクライアント スタブとサーバー インターフェイスを生成します。 Python、Rust、C++、その他多数の言語。 生成されたコードはシリアル化、逆シリアル化、 HTTP/2 フレーム化。

gRPC が輝く場所

• サービス間の通信。 高頻度のメッセージを交換する内部マイクロサービスは、バイナリ シリアル化と多重化ストリームの恩恵を受けます。
• 厳格な契約。 の .proto ファイルは唯一の信頼できる情報源です。 重大な変更は実行時ではなくコンパイル時に捕捉されます。
• 双方向ストリーミング。 gRPC は、サーバー ストリーミング、クライアント ストリーミング、および双方向ストリーミングをサポートします。 ライブ トランザクション フィードなどのリアルタイム機能は自然に適合します。
• ポリグロット環境。 Go サービスは、手動シリアル化コードを一切使用せずに、生成されたスタブを介して Python サービスを呼び出すことができます。

gRPC が不十分な点

• ブラウザのサポート。 ブラウザーはネイティブ gRPC 呼び出しを行うことができません。 grpc-web プロキシにより、複雑さと遅延の層が追加されます。
• 人間による可読性。 バイナリペイロードは検査できません curl またはブラウザ開発ツール。 デバッグには次のような特殊なツールが必要です grpcurl またはブルーム RPC。
• エコシステムの成熟度。 REST には、Postman、Swagger、API ゲートウェイ、レート リミッターなど、数十年にわたるツールがあります。 gRPC ツールは成長していますが、同じレベルではありません。
• 学習曲線。 チームは、プロトコル バッファー、proto3 構文、コード生成パイプライン、gRPC 固有のエラー処理パターンを学習する必要があります。

比較表

実際の意思決定の例

Stripe: 支払い用の REST

Stripe は、REST API を通じて数十億ドルの支払いを処理します。 エンドポイントは予測可能なものに従います パターン: POST /v1/payment_intents、 GET /v1/charges/:id。 すべての開発者 Stripe を統合する人は HTTP を知っています。 オンボーディングの摩擦はゼロに近いです。 Stripe が REST を選択した理由 対象者は、安定した文書化されたキャッシュ可能なエンドポイントを必要とする外部開発者です。

GitHub: 開発者ツール用の GraphQL

GitHub は、クライアント (デスクトップ アプリ、モバイル アプリ、 サードパーティ統合など）すべて、同じオブジェクトからの異なるデータが必要でした。 CI ツールにはコミットが必要です ステータスとチェック実行。 プロジェクト管理アプリには課題、ラベル、担当者が必要です。 モバイルアプリ 最小限のプロフィール ビューが必要です。 1 つの REST エンドポイントでは、大規模なオーバーフェッチがなければ 3 つすべてにサービスを提供することはできません。

Google: 内部サービス用の gRPC

Google は、内部サービス間を処理するために gRPC (「g」はリリースごとに異なる単語を表します) を構築しました 大規模なコミュニケーション。 サービス メッシュが 1 秒あたり数百万の RPC を処理する場合、その違いは次のとおりです。 JSON テキストの解析とプロトコル バッファーのバイナリ逆シリアル化の間が重要です。 Google が gRPC を選択した理由 対象者は内部であり、契約は厳格であり、スループットが主な制約です。

botoi が 150 以上のエンドポイントに REST を選択した理由

botoi の API は、DNS ルックアップ、電子メール検証、JSON フォーマット、QR コードなどの独立したユーティリティ エンドポイントを提供します。 生成、ハッシュ計算。 各エンドポイントは特定の入力を受け取り、特定の出力を返します。 DNS レコードを QR コードに接続するリレーショナル データ グラフはありません。

次の 3 つの要因により、REST が明確な選択となりました。

• ユニバーサルクライアントのサポート。 開発者は、Node.js、Python、Go、Ruby、PHP、 シェルスクリプトとAIエージェント。 REST はセットアップなしですべての環境で動作します。
• キャッシュ可能性。 静的リソースの GET エンドポイント (国検索や通貨リストなど) CDN 層での HTTP キャッシュの恩恵を受けます。 これにより、繰り返しリクエストの応答時間が 20 ミリ秒未満に抑えられます。
• 発見可能性。 各エンドポイントには、安定した URL、OpenAPI 仕様エントリ、およびインタラクティブな URL があります。 Scalar 経由のドキュメント。 新しい開発者は、1 分以内にエンドポイントを見つけてテストします。

GraphQL は複雑さを増すだけでメリットはありません。 走査するクエリ グラフはありません。 gRPC は ブラウザクライアントとシェルスクリプトを除外します。 REST は、このような問題に適したツールです。

1 つのシステム内でプロトコルを混在させる

このフレームワークは組織ごとではなく、境界ごとに適用されます。 多くの実稼働システムでは、次のようなプロトコルが組み合わされています。

• 外部 API レイヤー: 休む。 サードパーティの開発者と Webhook は HTTP + JSON を期待しています。
• クライアント側ゲートウェイ: グラフQL。 モバイルおよび Web クライアントは、複数のサービスからのデータを集約するゲートウェイにクエリを実行します。
• 内部サービス メッシュ: gRPC。 バックエンド サービスは、バイナリ ペイロードと厳密なコントラクトと通信します。

これは複雑さのための複雑さではありません。 それぞれの境界には、異なる対象者がいます。 制約。 プロトコルは制約と一致する必要があり、その逆ではありません。

意思決定チェックリスト

これを設計ドキュメントにコピーします。 それぞれの質問に答えると、プロトコルの選択が明らかになります。

1. API コンシューマは誰ですか? 外部開発者 (REST)、独自のフロントエンド チーム (GraphQL)、内部サービス (gRPC)。
2. クライアントはいくつのデータ形状を要求しますか? 1 つの形状 (REST)、多数の形状 (GraphQL)、固定コントラクト (gRPC)。
3. HTTP キャッシュは重要ですか? はい (REST)、場合によっては (手間をかけて GraphQL)、いいえ (gRPC)。
4. ストリーミングは必要ですか? いいえ (REST は問題ありません)、サブスクリプション (GraphQL)、双方向 (gRPC)。
5. クライアントは何語を使用していますか? すべて (REST)、JS/TS ヘビー (ここでは GraphQL ツールが最も強力です)、コード生成 (gRPC) を備えた多言語対応。
6. チームの現在の専門知識は何ですか? 誰もプロトコル バッファーを知らない場合、gRPC には莫大な立ち上げコストがかかります。 誰も GraphQL リゾルバーを知らない場合は、運用準備が整うまでに 1 か月の学習が必要です。

避けるべきよくある間違い

• 新しいと感じたので GraphQL を選択しました。 GraphQL はリゾルバーの複雑性とクエリを追加します コスト分析と N+1 の緩和。 API に固定形状の CRUD エンドポイントが 10 個ある場合、REST は 同じジョブをより少ないコードで実行できます。
• パブリック API として gRPC を選択する。 ユーザーはブラウザーから gRPC を呼び出すことができません。 curl、またはローコード ツールから。 いずれにせよ、その前に REST ゲートウェイを構築することになります。
• 複雑なデータ グラフには REST を選択します。 フロントエンド チームが 5 つの新しいサービスを要求した場合 既存のエンドポイントが返すデータが多すぎるか少なすぎるため、スプリントごとに「サマリー」エンドポイントが必要になります。 これは、GraphQL が調整オーバーヘッドを削減する可能性があることを示しています。
• チームの専門知識を無視する。 最も速く出荷されるプロトコルはあなたのチームのものです すでに知っています。 REST に精通したチームが gRPC に切り替える場合、ツールの開発に数週間を費やしてから gRPC に切り替えることになります。 ビジネスロジックを書くこと。