7 min read

WebアーキテクチャとRESTが生まれた理由——設計思想を歴史から理解する

なぜRESTはステートレスでなければならないのか。SOAPはなぜ負けたのか。Webを支える技術をもとに、RESTの誕生から設計思想の核心まで歴史的背景とともに整理する。

アーキテクチャインフラ

「RESTful APIを作っている」と言えるエンジニアは多いが、「なぜRESTはステートレスでなければならないか」を根拠を持って説明できる人は少ない。

RESTは単なるAPI設計の流行ではなく、Webが爆発的に普及した理由に直結した設計思想だ。その背景を理解すると、日常のAPI設計の判断が変わる。

Webが普及した本当の理由

Webは1991年に誕生してから30年で17億人のユーザと2億台のサーバを抱える巨大システムになった。これほどのスケールを実現できた理由は、アーキテクチャの設計にある。

Webが登場する前にも、インターネットとハイパーメディアと分散システムはそれぞれ存在していた。しかし、それらは互いに統合されていなかった。

Web以前の分散システムの問題

RPC（Remote Procedure Call）
└── ほかのコンピュータの機能をローカルの関数のように呼び出す
    → 問題: ネットワークの不安定性・プラットフォーム依存・密結合

CORBA・DCOM
└── 分散オブジェクトへの進化
    → 問題: 複雑な仕様・ベンダーロックイン・スケールの難しさ

これらの技術はシステムの規模が小さいうちは動いたが、インターネット規模になると破綻した。

Webはこの問題をどう解いたか

Webは3つの技術を組み合わせて解決した。

  1. HTTP — シンプルで統一されたプロトコル
  2. URI — すべてのリソースに一意のアドレスを付与
  3. HTML（ハイパーメディア） — リンクでリソース同士をつなぐ

この組み合わせが「ステートレスで、キャッシュ可能で、統一インターフェースを持つ」Webを実現した。

RESTの誕生

REST（Representational State Transfer）は2000年、Roy Fieldingの博士論文で提唱されたアーキテクチャスタイルだ。

Fieldingは「なぜWebはこれほどスケールするのか」を分析し、Webの設計原則を体系化した。それがRESTだ。

RESTを構成する6つの制約

REST = ULCODC$SS
├── Uniform Interface（統一インターフェース）
├── Layered System（階層化システム）
├── Client/Server（クライアント/サーバ分離）
├── On-Demand Code（コードオンデマンド） ※省略可能
├── Stateless（ステートレスサーバ）
└── Cache（キャッシュ）

ステートレスが重要な理由

サーバがクライアントの状態（セッション）を保持しないことで：

  • スケールが容易になる → どのサーバにリクエストを振っても同じ結果になる
  • 可用性が上がる → サーバ障害時に別サーバへの切り替えが簡単
  • 可視性が上がる → リクエスト1つで処理の内容が完結している

セッションをサーバに持つと、ユーザが「どのサーバに接続しているか」を固定しなければならない（スティッキーセッション）。これがスケールの障壁になる。

統一インターフェースが重要な理由

HTTPのGET・POST・PUT・DELETE・PATCHという少数のメソッドで、あらゆるリソース操作を表現する。

これにより：

  • クライアントはどのサーバとも同じ方法で通信できる
  • APIの仕様を学習するコストが下がる
  • 中間コンポーネント（プロキシ・キャッシュ）がHTTPを理解できる

SOAP対RESTの戦い——なぜSOAPは負けたか

2000年代前半、WebサービスはSOAP（Simple Object Access Protocol）とRESTの2派に分かれていた。

SOAPとは

XMLを使ってRPCスタイルのリモート呼び出しを行うプロトコル。

<!-- SOAPリクエストの例 -->
<soap:Envelope>
  <soap:Body>
    <getUserById>
      <id>123</id>
    </getUserById>
  </soap:Body>
</soap:Envelope>

「何でもPOSTでXMLを送る」スタイルで、HTTPをトランスポート層としてしか使っていない。GETもPUTもなく、すべてのリクエストが同じエンドポイントへのPOSTになる。

SOAPが敗れた理由

観点SOAPREST
シンプルさ複雑（WSDL・WS-*の仕様が膨大）シンプル（HTTPをそのまま使う）
キャッシュ不可能（すべてPOSTなのでキャッシュできない）GETはキャッシュ可能
学習コスト高い低い（HTTPを知っていれば使える）
ブラウザ対応難しい簡単

SOAPはHTTPの上にRPCの層を乗せることで、HTTPが持つキャッシュ・ステートレス・統一インターフェースという利点をすべて殺してしまった。Webのアーキテクチャに逆らった設計だったため、スケールしなかった。

RESTの誤解——「URIにCRUDを入れるな」は正しいか

「RESTful」を誤解しているコードをよく見る。

# ❌ RPCスタイル（URIに動詞を入れる）
POST /getUser
POST /createUser
POST /deleteUser

# ❌ 非REST（すべてのリソースをPOSTで操作）
POST /users/action?type=delete&id=123

# ✅ REST（HTTPメソッドで操作を表現）
GET    /users/123      # 取得
POST   /users          # 作成
PUT    /users/123      # 更新（全体）
PATCH  /users/123      # 更新（一部）
DELETE /users/123      # 削除

「RESTとは何か」ではなく「HTTPメソッドをどう使うか」の問題として理解すると、設計の迷いが減る。

現場への応用

この歴史的背景を理解してから、設計判断が変わった点が2つある。

1. 「なぜPOSTではなくPUTを使うか」を説明できるようになった

「PUTはべき等（同じリクエストを何度送っても結果が同じ）だから、リトライが安全」という根拠で説明できる。冪等性の重要性はWebの設計思想に根ざしている。

2. ステートレス設計を意識するようになった

セッションに依存したAPIを作ると、水平スケールが難しくなる。認証状態はJWTトークンとしてクライアントに持たせ、サーバはステートレスに保つ設計を選ぶようになった。

まとめ

RESTはWebのアーキテクチャの分析から生まれた設計思想だ。ステートレス・統一インターフェース・キャッシュの制約は、Webがインターネット規模でスケールするために必要なものとして導き出された。

「なぜそう設計するか」の根拠を持つことで、チーム内の設計議論が変わる。

詳細はWebを支える技術で体系的に学べる。

PR

Webを支える技術 ——HTTP、URI、HTML、そしてREST

Webを支える技術 ——HTTP、URI、HTML、そしてREST

山本陽平 著 ／ 技術評論社

Amazonで見る →

関連記事

↑