RESTとGraphQLの違い — 商品カードに「欲しい情報」をそろえる

ひよこ

商品名と値段だけ欲しいのに、APIからたくさん返ってきた！

ペンギン先生

取得項目をどう決めるかはAPI設計のポイントだね。RESTはリソースなどを中心にした設計原則、GraphQLは欲しいフィールドを問い合わせる言語と実行の仕組み。今回は同じ商品カードで比べよう。

ひよこ

RESTなら商品ごとにURLがある？

ペンギン先生

商品を/products/42のように識別し、GETで表現を読むHTTP APIの設計ができるよ。ただしURLを分けるだけでRESTの全制約を満たすわけではない。返す項目や関連情報をまとめるかも設計できるんだ。

ひよこ

GraphQLは何を送るの？

ペンギン先生

スキーマにある商品からnameとpriceYenが欲しい、とクエリで指定するよ。ないフィールドや権限のないデータを自由に取り出せるわけではない。公開する型と処理をサーバー側で用意するんだ。

ひよこ

それならいつも1回で速くなる？

ペンギン先生

通信をまとめやすいけれど、DBへの問い合わせ回数とは別だよ。画面から1回でもサーバー内部で何度も読めば遅くなる。RESTでもまとめた応答を設計できるので、回数だけで一律には決められないよ。

ひよこ

RESTのHTTPキャッシュは使いやすい？

ペンギン先生

GETの応答に適切なCache-Controlなどを設定すると再利用しやすいよ。GraphQLも対応サーバーのqueryならGETを使える。どちらも利用者別の応答を共有キャッシュへ混ぜないよう設計するんだ。

ひよこ

N+1問題ってなに？

ペンギン先生

一覧を1回読み、各行の詳細をN回読むような状態だよ。GraphQLではフィールドごとの取得を素直に書くと起こることがある。まとめて取得する方法やDataLoaderなどで改善し、実際のDB回数を確認するよ。

ひよこ

型があれば、認証も負荷対策も済む？

ペンギン先生

型は入力やフィールドの検証に役立つけれど、誰が読めるかは別に認可するよ。深さ・件数・処理量も制限する。APQでクエリを識別子にしても、それだけで許可したクエリだけに限定する仕組みにはならないんだ。

ひよこ

迷ったら何を比べればいい？

ペンギン先生

まず1つの画面の欲しい項目を書き、既存APIで取れるかを見る。画面ごとの形が多く変わるならGraphQLも候補。公開先の使いやすさ、キャッシュ、実装と保守の負担を比べよう。GitHubのように両方を使うこともできるよ。

商品カードに必要なのは「名前と値段」

同じ商品データでも、一覧画面には名前と値段、詳細画面には説明文や在庫も欲しいかもしれません。まず画面が必要とする項目を紙に書くところから始めます。

以下は仕様を比べるための架空の商品APIです。実際にアクセスするURLや、そのまま動くサーバーではありません。

HTTP APIの例

GET /products/42 に対して、設計した商品の表現が返ります。

{
  "id": 42,
  "name": "マグカップ",
  "priceYen": 1200,
  "description": "ひよこの絵が入ったカップ"
}

画面が説明文を使わないなら取得する情報が余ります。ただしRESTでも取得項目を指定する機能や、画面に合わせた集約を設計できます。「RESTは必ず全部返す・必ず複数回」と決まっていません。

GraphQLの例

サーバーのスキーマに product(id: ID!) と対象のフィールドがある場合、次のように選べます。

query ProductCard {
  product(id: "42") {
    name
    priceYen
  }
}

この設計で商品の取得に成功したときの応答例です。

{
  "data": {
    "product": {
      "name": "マグカップ",
      "priceYen": 1200
    }
  }
}

返る項目が注文に対応していることを見てみましょう。認可・取得失敗・nullableの設計によっては、エラーやnullを含む応答にもなります。

選び方の入口

まず1画面の必要項目をそろえ、通信量・待ち時間・実装の複雑さを比較します。画面が多い、形が変わる、といった課題があるならGraphQLを試す理由になります。導入するだけで速くなるわけではありません。

もう少し詳しく：1回の要求の裏側

N+1は「一覧1回＋行ごとの取得N回」のような問い合わせです。まとめて読む仕組みやDataLoaderで改善できますが、ネットワークの要求数が1だからDBも1回とは限りません。ページングやクエリの深さ・件数・コストの制限、権限の確認を設計します。

APQ（Automatic Persisted Queries）はクエリ本文の代わりにハッシュなどの識別子を送る方式です。ApolloのAPQでは、未登録のときに本文も送り登録します。許可済みのクエリだけに制限する仕組みや、認可の代わりにはなりません。GETのqueryや永続化クエリでキャッシュしやすくする場合も、利用者ごとのデータを誤って共有しないようにします。

TypeScriptでサーバーとクライアントを統一するならtRPCも候補です。型共有が役立つ一方で、外部の利用者や使える言語、実行時の入力検証なども考慮します。別の選択肢を増やす前に「誰が何を取りたいか」を決めましょう。

通信そのものはHTTPの仕組み、型付きのリモート呼び出しはgRPCとRESTで学べます。

参考資料

2026年10月9日確認。

• Fielding — REST — 設計制約
• GraphQL — Serving over HTTP — POST・GET・応答の形
• GraphQL — Performance — N+1・キャッシュ・処理量の制限
• GitHub — API comparison — 併用と機能差
• Apollo — APQ — 初回の本文登録と識別子
• tRPC — Introduction — TypeScriptの型共有