【図解で比較】REST vs GraphQL — API設計の2大スタイルを徹底解説

どっちもAPIの「設計スタイル」なんだけど、データの取り方がまったく違うんだよ。RESTは「リソースごとにURL（エンドポイント）を分ける」スタイルで、/users、/posts、/commentsみたいに情報の種類ごとにアクセス先が別々になるんだ。

GraphQLは「1つのエンドポイントに、欲しいデータの形をクエリとして送る」スタイルだよ。/graphqlという1つの窓口に「ユーザー名と、その人の投稿タイトルと、コメント数をください」って注文書を渡すイメージだね。

そうなんだよ。たとえばユーザーのプロフィールと投稿一覧とコメントが欲しい場合、RESTだと3回リクエストが必要になることがある。これを「アンダーフェッチング」って呼ぶんだ。逆に、ユーザー名だけ欲しいのにプロフィール全部が返ってくる「オーバーフェッチング」という問題もあるよ。

その通り！GraphQLでは「欲しいフィールドだけ」を指定できるから、1回のリクエストで必要なデータだけ過不足なく取得できるんだ。たとえば「user(id 1)の name と posts の title だけちょうだい」みたいにクエリを書くと、名前と投稿タイトルだけが返ってくるよ。

もちろんあるよ。RESTはURLごとにリソースが分かれてるから、HTTPキャッシュがすごく効きやすいんだ。ブラウザやCDNが「/users/1のレスポンスは5分間キャッシュ」みたいに自然にキャッシュできる。GraphQLは全部同じURLへのPOSTリクエストだから、HTTPキャッシュが効きにくいんだよね。

GraphQLはスキーマ定義言語（SDL）で「どんなデータがどんな型で返ってくるか」を厳密に定義するんだ。「User型にはid、name、postsがある」みたいに宣言するんだ。これのおかげで、リクエストを送る前に「この書き方は正しいか」をチェックできるし、ドキュメントも自動生成されるよ。RESTだとOpenAPI（Swagger）で後付けする必要があるんだ。

RESTは「リソースがシンプルで、キャッシュが重要なとき」に向いてるよ。公開APIや、マイクロサービス間の通信に多いね。GraphQLは「フロントエンドが複雑で、画面ごとに必要なデータが違うとき」に威力を発揮する。実際、GitHubはAPI v3がRESTで、v4をGraphQLに切り替えたんだよ。

GitHub以外にも、Facebook（GraphQLの生みの親）、Shopify、Yelp、Netlifyなど多くのサービスが採用してるよ。ただ、AWS・Google Cloud・Stripeなど「RESTのまま」の大手APIもたくさんある。どちらが優れてるというより、用途次第なんだ。

いいところに気づいたね。GraphQLではネストしたデータを1回のクエリで取れるけど、サーバー側では「ユーザー一覧を取得（1回）→ 各ユーザーの投稿を個別に取得（N回）」みたいにDB問い合わせが爆発することがあるんだ。これがN+1問題。対策としてDataLoaderというライブラリで「まとめてバッチ取得」するのが定番だよ。

パフォーマンス面では「Persisted Queries（永続化クエリ）」が重要だよ。クライアントが毎回長いクエリ文字列を送る代わりに、事前にサーバーに登録したクエリのハッシュだけ送る仕組みで、セキュリティとパフォーマンスの両方が向上する。大規模運用では「Federation」といって、複数のGraphQLサーバーを1つのスキーマに統合する技術も使われてるんだ。Apollo Federationが有名だね。

最近はtRPCという選択肢も注目されてるよ。TypeScriptのフルスタック開発で、APIの型をサーバーとクライアントで自動共有できるんだ。スキーマ定義なしで型安全が手に入るから、Next.jsなどTypeScript統一環境では非常に強力だよ。REST・GraphQL・tRPC、それぞれの強みを理解して使い分けるのが現代のAPI設計の基本だね。