REST
REST
リソース(データ)を中心に据え、HTTPの標準的な仕組みでやり取りするアーキテクチャスタイル。ステートレスで疎結合なので、公開APIや水平スケールに向く。
RPCとの思想の違い: 振る舞い vs データ
ここが一番の勘所です。
- RPC = 『操作(振る舞い)』を公開する。
createUser、deleteUserのように動詞中心。 - REST = 『リソース(データ)』を公開する。
/usersという名詞に対し、HTTPの動詞(GET/POST/DELETE)で操作する。
図を描画中...
RESTでは『1つのリソース(/users)に対し、標準のHTTP動詞で操作する』という統一感があります。新しい操作のために新APIを作る必要が減ります。
RESTの4つの柱
- URIでリソースを識別:
/users/123がユーザー123を一意に指す。 - HTTP verbで操作: GET(取得)、POST(作成)、PUT(更新)、DELETE(削除)。
- 自己記述的なエラー: ステータスコード(200成功、404なし、500エラー)で結果を伝える。
- HATEOAS: レスポンスに『次にできる操作』へのリンクを含め、クライアントを誘導する。
ステートレスの威力
RESTの各リクエストは自己完結しています。サーバーは前のリクエストの状態を覚えていません(ステートレス)。
これが水平スケールに効きます。状態を持たないので、どのサーバーにリクエストが振られても同じように処理できる。ロードバランサーで台数を自由に増やせます(『ロードバランサー』の章のステートレスの話と直結)。
図を描画中...
RPC vs REST 早見表
| 操作 | RPCの例 | RESTの例 |
|---|---|---|
| 登録 | POST /signup | POST /persons |
| 退会 | POST /resign {personid} | DELETE /persons/1234 |
| 取得 | GET /readPerson?personid=1234 | GET /persons/1234 |
つまずきポイント(短所)
- 単純なリソース階層に収まらないデータ(複雑な操作)は表現しづらい。
- 関連データをまとめて取りたいとき、複数回リクエストが要る(例: ユーザー→その投稿→各投稿のコメント)。モバイルなど往復コストが高い環境で不利。GraphQLはこの不満から生まれた。
- フィールドが増えるとレスポンスが肥大化しやすい。
使い分けの結論
- 外部公開・汎用・疎結合 → REST(public HTTP API)。
- 内部・性能重視・密結合OK → RPC。