RESTとGraphQLの比較
基本アーキテクチャの違い
REST API
リソースベース設計: URL がリソースを表現
HTTPメソッド活用: GET、POST、PUT、DELETE
複数エンドポイント: リソースごとに異なるURL
ステートレス: サーバーはクライアント状態を保持しない
code: (http)
GET /api/users/123
GET /api/users/123/posts
GET /api/posts/456/comments
PUT /api/users/123
DELETE /api/posts/456
GraphQL
スキーマベース設計: 型システムで構造を定義
単一エンドポイント: すべての操作が /graphql
クエリ言語: 宣言的なデータ取得
強力な型システム: コンパイル時型チェック
code: (graphql)
query {
user(id: 123) {
name
posts {
title
comments { content }
}
}
}
データ取得パターンの比較
Over-fetching / Under-fetching 問題
table:table
課題 REST GraphQL
Over-fetching 不要なフィールドも取得 必要なフィールドのみ指定
Under-fetching 複数リクエストが必要 1回のリクエストで完結
Waterfall問題 順次リクエストで遅延 並列データ取得
実例：ユーザープロフィール画面
REST APIの場合（3回のリクエスト）：
code: (http)
GET /api/users/123
→ { "id": 123, "name": "田中", "email": "tanaka@example.com", "bio": "..." }
GET /api/users/123/posts
→ "id": 1, "title": "投稿1" }, { "id": 2, "title": "投稿2" }
GET /api/users/123/followers
→ "id": 456, "name": "佐藤" }, { "id": 789, "name": "鈴木" }
GraphQLの場合（1回のリクエスト）：
code: (graphql)
query UserProfile($userId: ID!) {
user(id: $userId) {
name
email
posts(first: 10) {
title
createdAt
}
followers(first: 5) {
name
}
}
}
パフォーマンス特性の比較
REST APIの特性
👍 メリット
HTTPキャッシュ活用: ブラウザ・CDNでの効率的キャッシュ
シンプルなキャッシュ戦略: URLベースでキャッシュ管理が容易
プリフェッチ可能: 予測可能なエンドポイント
CDN最適化: 静的コンテンツとの相性が良い
👎 デメリット
ネットワーク往復回数: 複数リクエストによる遅延
データ転送量: 不要なデータも含む
リクエスト管理: 複数APIの状態管理が複雑
GraphQLの特性
👍 メリット
最小データ転送: 必要なデータのみ
単一リクエスト: ネットワーク往復最小化
並列データ取得: バックエンドでの効率的処理
モバイル最適化: 帯域幅の節約
👎 デメリット
複雑なキャッシュ: クエリ内容に依存するため難しい
N+1問題: 実装者の注意が必要
クエリ複雑性: 悪意あるクエリによるサーバー負荷
開発体験の比較
型安全性
table:table
観点 REST GraphQL
API定義 OpenAPI/Swagger Schema Definition Language
型生成 手動またはツール依存 自動生成（豊富なツール）
コンパイル時チェック 限定的 強力な型チェック
IDE支援 基本的 豊富（補完・検証）
開発ツール
REST開発ツール：
curl, httpie
成熟したエコシステム
GraphQL開発ツール：
GraphQL Playground, GraphiQL
Apollo DevTools
Code Generation ツール
Schema Registry
APIドキュメント
REST：
OpenAPI/Swagger での記述
手動でのドキュメント維持が必要
エンドポイントごとの個別説明
GraphQL：
スキーマがそのままドキュメント
自己記述的API
イントロスペクション機能
スケーラビリティの比較
チーム規模別の適性
小規模チーム (1-5人)
table:table
REST GraphQL
✅ 学習コスト低 ❌ 学習コスト高
✅ 迅速な開発開始 ❌ 初期設定が複雑
✅ シンプルな運用 ❌ 運用知識が必要
大規模チーム (10人以上)
table:table
REST GraphQL
❌ API調整コスト高 ✅ フロント・バック分離
❌ バージョン管理複雑 ✅ スキーマ進化
❌ 複数チーム調整困難 ✅ 契約によるチーム独立
システム規模別の特性
小規模システム
REST: CRUD中心なら最適
GraphQL: オーバーエンジニアリングのリスク
大規模・複雑システム
REST: マイクロサービス間通信に適している
GraphQL: 複雑なデータ関係の統合に優秀
具体的な使い分けシナリオ
REST APIを選ぶべき場面
✅ 強く推奨
シンプルなCRUD操作
マイクロサービス間通信
ファイルアップロード/ダウンロード
キャッシュ戦略が重要
外部パートナー向けAPI
レガシーシステム統合
📱 具体例
code: (http)
# 決済API
POST /api/payments
GET /api/payments/123
# ファイル管理
POST /api/files/upload
GET /api/files/download/abc123
# ヘルスチェック
GET /api/health
GraphQLを選ぶべき場面
✅ 強く推奨
モバイルアプリケーション
複雑なデータ関係
リアルタイム機能
多様なクライアント
頻繁なUI変更
BFF (Backend for Frontend)
📱 具体例
code: (graphql)
# SNSアプリのタイムライン
query Timeline {
me {
feed(first: 20) {
post {
author { name, avatar }
content
likes { count }
comments(first: 3) {
author { name }
content
}
}
}
}
}
# Eコマースの商品詳細
query ProductDetail($id: ID!) {
product(id: $id) {
name
price
images
reviews(first: 5) {
rating
comment
}
recommendations {
name
price
}
}
}