Webの基本とRESTの考え方をわかりやすく解説
Webは単なる「ホームページ表示の仕組み」にとどまらず、ユーザーインターフェースやAPIとしても使われています。本記事では、Webの基礎技術と、REST（Representational State Transfer）というWebアーキテクチャの考え方をわかりやすく解説します。
Webの主な用途
- Webサイト：HTMLやCSSを使った従来の情報提供型のページ。
- ユーザインタフェースとしてのWeb：フォームやボタンなどを備えたWebアプリの画面。
- プログラム用APIとしてのWeb：人間ではなくソフトウェアが通信するための仕組み（例：JSON API）。
Webを支える基本技術
- HTTP（Hypertext Transfer Protocol）：Webで情報をやり取りする通信プロトコル。
- URI（Uniform Resource Identifier）：Web上の情報に一意な名前を与える識別子。
- HTML（HyperText Markup Language）：Webページの構造を記述するための言語。
RESTとは何か？
RESTは、HTTPを活用した分散システムの設計スタイルです。単なるハイパーテキストの転送にとどまらず、「リソースの状態の表現（Representation of Resource State）」をやり取りするという考えに基づいています。
アーキテクチャスタイルとは？
複数のシステムに共通する設計の流儀を抽象化したものです。例として、以下があります：
- MVC（Model-View-Controller）
- パイプ＆フィルタ（Pipe and Filter）
- イベント駆動型（Event System）
RESTもその一種であり、ネットワークベースのシステムに適用されます。
アーキテクチャとその階層
- 実装レベル：Apache、Chromeなどのソフトウェア
- アーキテクチャ：ブラウザやWebサーバなどの構成
- アーキテクチャスタイル：REST、クライアント/サーバなどの設計指針
RESTを構成する6つのアーキテクチャスタイル
- クライアント／サーバ：UIとデータ処理を分離する
- ステートレスサーバ：サーバ側は状態を保持しない
- キャッシュ：クライアント側で結果を再利用する
- 統一インタフェース：HTTPメソッドに限定して操作を行う
- 階層化システム：中継サーバを挟んでも透過的に動作する
- コードオンデマンド（任意）：クライアントでコードを動的に実行
※すべてを厳密に満たす必要はなく、システムの要件に合わせて必要可否を判断する必要があります。
リソースとURIの重要性
RESTでは、Web上のあらゆる情報はリソースとして扱われ、URIによって一意に識別されます。
URIの特性
- アドレス可能性：URIがリソースを指し示す能力
- 不透明性：クライアントはURIの中身を解析しない
- 複数URI：同じリソースに複数のURIが存在することもある
例：http://example.com/todayhttp://example.com/2025-07-01
両方が「今日のデータ」を示す可能性があります。
URI設計のポイント
- 言語やメソッド名をURIに含めない
- セッションIDをURIに埋め込まない
- 動詞ではなく名詞でリソースを表現する
- URIの変更時はリダイレクトで対応する
- 言語切り替えにはコンテントネゴシエーションを利用
HTTPの基礎とRESTとの関係
ステートレス vs ステートフル
- ステートフル：サーバが状態を保持し、複雑でスケールしづらい
- ステートレス：リクエストが独立しており、スケーラブルだが冗長
主なHTTPメソッド
| メソッド | 用途 |
|---|---|
| GET | リソースの取得 |
| POST | 子リソースの作成、データ送信 |
| PUT | リソースの作成・更新 |
| DELETE | リソースの削除 |
| HEAD | メタ情報の取得 |
| OPTIONS | 利用可能なメソッドの確認 |
| TRACE | ループバック診断 |
| CONNECT | トンネル接続の確立（HTTPSなど） |
まとめ
RESTは、HTTPの標準的な機能（メソッド、URI、ヘッダなど）を最大限に活用するシンプルで拡張性の高い設計思想です。API設計に携わる開発者にとって、RESTの理解は今や必須です。
今回紹介した基本的な考え方を押さえておけば、実践的なREST APIの設計にも自信をもって取り組めるはずです。
コメント