REST vs GraphQL vs gRPC — それぞれいつ選びますか?

Question

IT Interview Practice · Accepted Answer

これらは 3 つの異なる API パラダイムで、それぞれ異なる制約に最適化されています。普遍的な勝者はありません — 正しい選択は **消費者、データの形、ネットワーク** に依存します。

## 3 つを一目で

```text
           REST                 GraphQL              gRPC
Style      resources + HTTP     single query graph   RPC (call methods)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binary)
Fetching   fixed endpoints      client picks fields  fixed methods
Schema     optional (OpenAPI)   strong, typed        strong, .proto
Browser    native, cacheable    needs client lib     limited (needs proxy)
```

## REST

素の HTTP 上のリソース指向。public API、CRUD サービス、HTTP キャッシュ・遍在性・単純さの恩恵を受けるものには **これを選びます**。弱点は **over-fetching** (1 フィールドしか要らなくても `/users/42` 全体を得る) と **under-fetching** (`N+1` 問題: user を取得し、次に各 order を取得するためにループする) です。

```http
GET /users/42            → ユーザー全体
GET /users/42/orders     → 2 回目のラウンドトリップ
```

## GraphQL

**client が欲しいものを正確に指定する** 単一のエンドポイントで、1 つのクエリで over/under-fetching を解決します。リッチなフロントエンド (特にラウンドトリップが高コストなモバイル) や、多くの client が同じデータの異なる形を必要とするときに **これを選びます**。

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← 1 回のラウンドトリップ、正確な field
```
トレードオフ: HTTP キャッシュが難しく (すべてが `/graphql` への `POST`)、素朴な resolver は高コストな `N+1` データベースクエリを隠しえます。

## gRPC

**HTTP/2** 上で **Protobuf** を使う契約優先の RPC。バイナリで多重化され、高速でコンパクト、ストリーミングをサポートします。パフォーマンスと厳格な型付けが重要な microservices バックエンドでの **内部 service-to-service** 通信に **これを選びます**。弱点: ブラウザサポートが貧弱 (grpc-web のようなプロキシが必要) で、人間が読めません。

## 選び方

```text
Public API、CRUD、caching、広い到達範囲     → REST
複雑/多様な frontend のデータ要件          → GraphQL
高性能な内部 microservices               → gRPC
(実システムは混在させる: エッジで REST/GraphQL、サービス間で gRPC。)
```

## なぜ重要なのか

シニアレベルでは、面接官は定義よりも、**制約に対して選択を正当化できるか** を気にします — この質問は本当は「ハイプを追うのでなく、技術を問題に合わせられるか?」です。最強の答えは各々が解決する痛みに錨を下ろします: GraphQL は要求の厳しいフロントエンドの over/under-fetching を殺すために存在し、gRPC は内部サービス呼び出しを高速で強く型付けするために存在し、REST はデフォルトのままです。なぜなら HTTP キャッシュ、ツール、普遍的な馴染みが、public や CRUD 型 API にとって膨大な実用的利点だからです。決定的に、シニアエンジニアは **二者択一ではない** と指摘します — 一般的なアーキテクチャは public のエッジで REST か GraphQL、バックエンド microservice 間で gRPC — そして具体的なトレードオフ (GraphQL のキャッシュと `N+1` のリスク、gRPC の弱いブラウザ事情) を挙げます。機能を暗唱する能力でなく、適合性とコストについてのその推論こそがシグナルです。

3 つを一目で

REST

GraphQL

gRPC

選び方

なぜ重要なのか

関連する質問