メインコンテンツまでスキップ

🧩 REST / gRPC / GraphQL（同期リクエスト駆動の統合スタイル）

✅ このスタイルの概要​

サービス間を「リクエスト＆レスポンス」で同期的につなぐ代表的な 3 つのプロトコル／API スタイル を俯瞰するページである。

  • REST：リソース指向の HTTP API スタイル
  • gRPC：IDL ベースの高速バイナリ RPC
  • GraphQL：クライアント駆動の柔軟なクエリ API

ここでは「どのような思想で何を解決しようとしているのか」を軸に整理する。

✅ 解決しようとした問題​

3 者とも、基本的には サービス間通信をシンプルに、再利用可能にしたい という課題に向き合っているが、焦点は少しずつ異なる。

  • REST：

    • Web / HTTP の世界で、リソース指向かつ統一されたインターフェースを提供したい
    • リンク指向・キャッシュ可能な API を設計したい

  • gRPC：

    • マイクロサービス間の通信で、JSON/HTTP のオーバーヘッドを減らし、高速で型安全な通信を実現したい
    • 双方向ストリーミングや厳密なインターフェース定義（IDL）が欲しい

  • GraphQL：

    • クライアントごとに必要なデータが違う状況で、「N+1 REST 呼び出し」や過不足の多いレスポンスを解消したい
    • フロントエンド主導でスキーマとデータ取得形態を設計したい

✅ 基本思想・ルール​

REST​

  • HTTP メソッド（GET/POST/PUT/DELETE...）＋ URL でリソース操作を表現
  • ステータスコード・ヘッダ・キャッシュなど HTTP の仕組みを活用
  • HATEOAS（リンクを通じた遷移）など、ハイパーメディア指向の設計思想

gRPC​

  • Protocol Buffers（proto）などの IDL でインターフェースを定義
  • バイナリ形式＋ HTTP/2 による高速・効率的な通信
  • Unary / Server Streaming / Client Streaming / Bidirectional Streaming をサポート

GraphQL​

  • Schema による型付き API 定義
  • クライアントがクエリで「欲しいフィールドのみ」を宣言的に指定
  • 単一エンドポイントで複数リソースを組み合わせた取得が可能

✅ 得意なアプリケーション​

REST​

  • パブリック API / Web API 全般
  • キャッシュや HTTP インフラを活かしたい API
  • リソース中心の CRUD API

gRPC​

  • マイクロサービス間の内部通信
  • 高スループット・低レイテンシが重要なバックエンド
  • 型安全なインターフェースが重要な多言語環境

GraphQL​

  • フロントエンドからの柔軟なデータ取得が必要な BFF 的役割
  • モバイル／SPA でのネットワーク回数削減
  • UI のバリエーションや A/B テストが多いプロダクト

❌ 不向きなケース​

REST​

  • クライアントごとに必要なデータ構造が大きく異なる場合
  • 高速な双方向ストリーミングが必要な場合

gRPC​

  • ブラウザから直接叩くパブリック API（標準ブラウザからの利用は JSON/REST より敷居が高い）
  • HTTP デバッグツールで確認したい運用現場

GraphQL​

  • 非常にシンプルな CRUD API（GraphQL サーバのコストがオーバーキル）
  • キャッシュ戦略がシンプルな REST で十分なケース
  • スキーマ設計・N+1 問題対策の知見がチームにない場合

✅ 歴史（系譜・親スタイル）​

  • REST：Fielding の論文を起点に、Web アーキテクチャとして普及
  • gRPC：Google 内部技術をもとに OSS 化され、マイクロサービス時代の RPC として拡大
  • GraphQL：Facebook がフロントエンドの課題から生み出し、その後 OSS として広く利用されるように

3 者は対立軸というより、Web API / サービス間通信の進化の別方向 と捉えると理解しやすい。

✅ 関連スタイル​

✅ 代表的なフレームワーク​

REST​

  • Spring MVC / Spring Boot
    エンタープライズ向け Web/API サーバの代表格。RESTful API の典型例として参照されることが多い。

  • Ruby on Rails
    リソース指向のルーティングとコントローラで RESTful API を構築しやすい。

  • Django REST Framework
    Django 上で REST API を実装するためのデファクトスタンダード。

  • Express / FastAPI など
    軽量な Web フレームワークで、シンプルな REST API を素早く構築できる。

gRPC​

  • gRPC 公式ライブラリ（Go / Java / C# / Node.js など）
    IDL（proto）とコード生成を通じて、高速かつ型安全な RPC を提供する。

  • Envoy / gRPC-Web
    ブラウザから gRPC を扱うためのプロキシやアダプタ。

GraphQL​

  • Apollo Server / Apollo Gateway
    Node.js ベースの GraphQL サーバ／フェデレーション実装。

  • Hasura
    DB スキーマから即座に GraphQL API を生成するバックエンド。

  • GraphQL Java / Hot Chocolate (.NET) など
    各言語での GraphQL サーバ実装。

✅ このスタイルを支えるデザインパターン​

REST / gRPC / GraphQL は通信プロトコルだが、その裏では次のようなデザインパターンがよく使われる。

  • Facade
    複数のドメイン操作を 1 つの API としてまとめ、クライアントから見た入口を簡潔にする。

  • Adapter
    内部のモデル／インターフェースと外部公開 API のデータ形式の差を吸収する。

  • Proxy
    認証・キャッシュ・レートリミットなど、通信経路上での制御を追加する際に用いられる。

  • Strategy
    バージョン違いやクライアント別の振る舞いを切り替える場合に利用される。

  • Template Method
    共通のリクエスト処理フロー（認証 → バリデーション → 処理 → レスポンス整形）を統一する。

✅ まとめ​

REST / gRPC / GraphQL は、

  • 同じ「リクエスト＆レスポンス型の統合」でも、
  • 解決したい問題と得意領域が少しずつ異なる

スタイルである。

選択の際は、

  • 誰が主役か？（クライアント／バックエンド／サービス間）
  • 何がボトルネックか？（帯域／レイテンシ／開発速度／柔軟性）

といった観点から、適材適所で組み合わせて使うのが現実的である。