【比較】RESTとGraphQLの違い¶

Web API（アプリケーション間でデータをやり取りするためのインターフェース）の設計において、長らく主流であった「REST」と、Facebook（現Meta）社内で開発され、その後オープンソース化されて採用が広がっている「GraphQL」。この2つは、APIとのコミュニケーション方法において、根本的なアプローチの違いがあります。

概要¶

項目	REST (Representational State Transfer)	GraphQL
アーキテクチャ	アーキテクチャスタイル（設計上の制約の集合）	クエリ言語＋それを実行するランタイム
エンドポイント	複数（リソースごとにURLが存在）	単一（通常 `/graphql` のみ）
データ取得	サーバー側が定義した固定のデータ構造	クライアント側が必要なデータを指定
課題	オーバーフェッチ／アンダーフェッチが発生しやすい	学習コスト、複雑なクエリによる性能問題
HTTPメソッド	GET, POST, PUT, DELETEなどを使い分ける	主にPOST（仕様上は特定トランスポート非依存）
型システム	なし（OpenAPIなどで仕様を別途定義）	あり（スキーマで厳密に型を定義）
例えるなら	レストランのセットメニュー	アラカルト（単品注文）

一言で言うと、RESTは「リソース（情報）ごとに用意された窓口（URL）を叩く」 アーキテクチャであり、GraphQLは「一つの大きな窓口に必要なものだけを細かく注文する」 ための言語です。

なお当サイトには「REST・gRPC・WebSocketの違い」もあります。あちらはトランスポート・ストリーミング・契約の軸の比較で、本記事（クエリ表現力／オーバーフェッチ・アンダーフェッチの軸）とは観点が異なる補完関係です。

詳細比較¶

1. REST (Representational State Transfer)¶

RESTは、Webの原則（HTTPメソッド、ステートレス性など）に基づいてシステムを設計するためのアーキテクチャスタイル（設計上の制約の集合）です。MDN も REST を「効率的・信頼性・スケーラビリティを実現するソフトウェアアーキテクチャの設計制約の集まり」と定義しており、プロトコルや標準仕様そのものではありません。「リソース」という概念が中心にあり、すべての情報（ユーザー、商品など）は一意なURL（エンドポイント）で識別されます。

主な特徴¶

リソース指向: /users や /users/1 のように、URLが操作対象のリソースを表します。
HTTPメソッドの活用: リソースに対する操作をHTTPメソッドで表現します。
- GET: リソースの取得
- POST: リソースの新規作成
- PUT/PATCH: リソースの更新
- DELETE: リソースの削除
ステートレス: サーバーはクライアントの状態を保持せず、各リクエストは完結している必要があります。
オーバーフェッチとアンダーフェッチ:
- オーバーフェッチ: エンドポイントが固定のデータ構造を返すため、クライアントに不要なデータまで含まれてしまう問題。例えば、ユーザー名だけ欲しいのに、/users/1 を叩くと住所や電話番号まで返ってくるケース。
- アンダーフェッチ: 欲しい情報が複数のリソースにまたがっている場合、何度もAPIを呼び出す必要がある問題。例えば、ユーザー情報とその投稿一覧を取得するために、/users/1 と /users/1/posts の2回のリクエストが必要になるケース。

RESTはシンプルで理解しやすく、Webの標準技術に基づいているため、多くのWebサービスで採用されています。

2. GraphQL¶

GraphQLは、APIのためのクエリ言語であり、定義した型システムを用いてクエリを実行するサーバー側ランタイムでもあります（公式定義）。クライアントが必要なデータの構造をリクエストに記述できるのが最大の特徴で、これにより、RESTが抱えていたオーバーフェッチやアンダーフェッチの問題を解決します。

主な特徴¶

単一エンドポイント: 通常、すべてのリクエストは単一のURL（例: /graphql）にPOSTメソッドで送信されます（GraphQL 仕様自体は特定のトランスポートに依存しませんが、実運用では HTTP POST が一般的です）。
クライアント主導のデータ取得: クライアントは「クエリ」と呼ばれる要求を送信し、欲しいデータとその構造を自由に指定できます。
```
# ユーザーID:1のユーザー名と、そのユーザーの投稿のタイトルだけを取得するクエリ
query {
  user(id: "1") {
    name
    posts {
      title
    }
  }
}
```
このクエリにより、1回のリクエストで必要なデータだけを過不足なく取得できます。 - 厳密な型システム: サーバー側で「スキーマ」を定義し、APIで扱えるデータの型や関係性を厳密に記述します。これにより、APIの仕様が明確になり、開発ツールによる支援（入力補完など）も受けやすくなります。 - 操作の分類: - Query: データの取得（RESTのGETに相当） - Mutation: データの作成・更新・削除（POST, PUT, DELETEに相当） - Subscription: リアルタイムなデータ更新の購読

GraphQLは、特に複数のデータソースを扱う場合や、多様なクライアント（Web、モバイルアプリなど）がそれぞれ異なるデータ要件を持つ場合に強力な柔軟性を発揮します。

よくある誤解¶

誤解1：「REST はプロトコル／標準仕様である」 — 誤りです。REST は HTTP のようなプロトコルではなく、設計上の制約の集合（アーキテクチャスタイル）です。MDN も「a group of software architecture design constraints」と定義しています。HTTP API が慣習的に "RESTful" と呼ばれていても、必ずしも全制約を満たすわけではありません。
誤解2：「GraphQL は単なるデータベースのクエリ言語（SQL のようなもの）」 — 誤りです。GraphQL 公式は「a query language for your API, and a runtime for fulfilling those queries with your existing data」と定義します。特定のデータベースやストレージに紐づくものではなく、API の問い合わせ言語＋実行ランタイムです。
誤解3：「GraphQL は HTTP/POST に固定されたプロトコル」 — 不正確です。GraphQL 仕様はトランスポート非依存で、HTTP POST は最も一般的な運用形態にすぎません。「主に POST」は実務上の傾向であって仕様上の制約ではありません。
誤解4：「GraphQL を使えば常にパフォーマンスが上がる」 — 誤りです。GraphQL はオーバー／アンダーフェッチを抑えられますが、無制限に深い・複雑なクエリは N+1 問題やサーバー負荷を招きます。HTTP キャッシュも REST ほど単純には効きません。トレードオフがあります。
誤解5：「REST と GraphQL は二者択一で、片方が新しいから優れている」 — 不正確です。両者はトレードオフ関係にあり、RESTful API の前段に GraphQL サーバーを置く併用構成も実在します。要件次第で選ぶ／併用するものです。

実務での選び分け¶

RESTを選ぶケース:
- APIがシンプルで、リソースの構造が固定的な場合。
- HTTPキャッシングなど、Webの標準的な仕組みを最大限に活用したい場合。
- プロジェクトメンバーがRESTに慣れ親しんでいる場合。
GraphQLを選ぶケース:
- クライアントごとに必要なデータが大きく異なる複雑なアプリケーション。
- モバイルアプリなど、通信量を最小限に抑えたい場合。
- 複数のマイクロサービスやデータベースからデータを集約するAPIを構築する場合。

両者はトレードオフの関係にあり、プロジェクトの要件やチームのスキルセットに応じて最適なものを選択することが重要です。RESTfulなAPIの前にGraphQLサーバーを配置し、両者を併用するアーキテクチャも存在します。

判断軸：①クライアントのデータ要件が固定的か多様か ②オーバー／アンダーフェッチを問題視するか ③HTTP キャッシュ等の Web 標準を活かしたいか ④スキーマ（型）を契約として強制したいか ⑤チームの習熟度と運用コスト。

ひとことまとめ¶

REST はリソースごとの複数エンドポイントを叩くアーキテクチャスタイル、GraphQL は単一エンドポイントへ「必要なものだけ」を問い合わせるクエリ言語＋ランタイム。オーバー／アンダーフェッチとクエリ表現力の軸で選び分けます（トランスポートやストリーミングの軸は別記事 REST・gRPC・WebSocket を参照）。

出典・参考¶

MDN「REST」（REST は効率的・信頼性・スケーラブルな分散システムを実現するソフトウェアアーキテクチャの設計制約の集合。プロトコルや標準ではない）: https://developer.mozilla.org/en-US/docs/Glossary/REST
GraphQL 公式「Introduction to GraphQL」（GraphQL は API のためのクエリ言語であり、定義した型システムでクエリを実行するサーバー側ランタイム。クライアントが必要なものだけを要求できる）: https://graphql.org/learn/
GraphQL 公式サイト（A query language for your API。単一エンドポイント・型システム・クライアント主導のデータ取得）: https://graphql.org/
MDN「HTTP request methods」（GET/POST/PUT/DELETE 等の各メソッドの意味）: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods
当サイト「REST・gRPC・WebSocketの違い」（本記事と補完関係：トランスポート／ストリーミング／契約の軸の比較）