PART 01 — RESTとgRPCの立ち位置
「スタイル」と「実装」の非対称性を理解する

なぜ今この比較なのか

かつて Web API といえば事実上 REST（より正確には HTTP+JSON）一択だった。しかしマイクロサービス化が進み、 1 リクエストの裏で複数のサービスが相互に通信するようになると、サービス間（内部）通信の効率とスキーマの厳密さが 無視できないコストとして表面化してきた。ここに gRPC が広まった背景がある。

一方でブラウザやモバイル、社外公開 API の世界では、依然として REST が圧倒的に扱いやすい。 つまり現代のシステムでは「外向きは REST、内部は gRPC」のように、両者を適材適所で使い分ける構成が現実的な選択肢になっている。 だからこそ「どちらか一方が優れている」ではなく、「どの観点でどう選ぶか」を言語化することに価値がある。

REST とは — アーキテクチャスタイル

REST（Representational State Transfer）は、Roy Fielding が 2000 年の博士論文で定義した アーキテクチャスタイルであり、特定のライブラリやプロトコル製品ではない。 リソースを URI で識別し、HTTP メソッド（GET / POST / PUT / DELETE など）でそのリソースに対する操作を表現する、という「設計の作法」を指す。

現場で「REST API」と呼ばれるものの多くは、厳密には Fielding の定義（特に HATEOAS）を満たさない HTTP + JSON のリソース指向 APIである。本シリーズでも、この実務的な意味での REST を対象にする。

GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json

# レスポンス
HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "Taro Yamada",
  "email": "taro@example.com"
}

REST が前提とする代表的な性質は次の通り。

• リソース指向 — 「ユーザー」「注文」などの名詞（リソース）を URI で表す
• 統一インターフェース — 操作は HTTP メソッドの意味論に従う（GET は取得、DELETE は削除…）
• ステートレス — サーバーはリクエスト間でクライアントの状態を保持しない
• 表現の自由 — ボディの形式は JSON でも XML でもよい（実務では JSON が主流）

gRPC とは — HTTP/2 + Protocol Buffers の RPC

gRPC は Google が公開した RPC（Remote Procedure Call）フレームワークである。 「リソースを操作する」のではなく「リモートのメソッドを呼び出す」という発想に立つ。 通信路には HTTP/2 を使い、データのシリアライズには Protocol Buffers（protobuf） を使う。

gRPC ではまず .proto ファイルにサービス（メソッド群）とメッセージ（型）を定義し、 そこからクライアント／サーバー双方のコードを自動生成する。型と契約がコードに強制されるのが大きな特徴だ。

syntax = "proto3";

package user.v1;

// サービス = 呼び出せるメソッドの集合
service UserService {
  rpc GetUser(GetUserRequest) returns (User);
}

// メッセージ = やり取りする型
message GetUserRequest {
  int64 id = 1;          // フィールド番号は互換性の要
}

message User {
  int64  id    = 1;
  string name  = 2;
  string email = 3;
}

gRPC が標準で備える代表的な性質は次の通り。

• スキーマファースト — .proto が唯一の契約。クライアント／サーバーは生成コードを共有する
• バイナリ表現 — protobuf はコンパクトな2進形式で、JSON より小さく速い
• HTTP/2 前提 — 多重化（1接続で並列）・ヘッダ圧縮・双方向ストリーミングを活用
• 4 つの通信方式 — Unary（1対1）に加えてサーバー／クライアント／双方向ストリーミングを持つ

「スタイル」と「実装」の非対称性

ここが本シリーズで最初に押さえておきたい最重要ポイントだ。REST と gRPC は同じ階層のものではない。

つまり REST は「設計の指針」であり、gRPC は「指針＋実装が一体になった製品」だ。 この非対称性を理解しないまま「REST vs gRPC」を語ると、議論が噛み合わなくなる。 たとえば「gRPC はスキーマが厳密」という長所は、REST 側でも OpenAPI を導入すれば近づけられる。 逆に「REST はブラウザからそのまま叩ける」という長所は、gRPC では gRPC-Web というブラウザ向けの別レイヤーが必要になる。

RPC 指向とリソース指向の発想の差

実装に入る前に、両者の発想（メンタルモデル）の違いを掴んでおくと、以降の設計観点が腹落ちしやすい。 同じ「ユーザーを取得する」という処理を、両者は次のように考える。

「ユーザーを退会させる」のようなCRUD に綺麗に収まらない操作を考えると差が分かりやすい。 REST では POST /users/42/deactivation のようにリソース化を工夫する必要があるが、 gRPC では DeactivateUser(id) というメソッドを足すだけで自然に表現できる。 逆に「リソースの一覧をページングで取得」のような定型操作は REST の統一インターフェースが綺麗にハマる。

このシリーズの読み方

本シリーズは全 5 回で構成する。設計観点の整理 → 判断軸 → 実例での移行、という順で深掘りしていく。