📖

「Web を支える技術」を読み終えて 〜 技術書の備忘録

に公開
Web
idea

『Web を支える技術』を読み終えたので、自分の中で特に重要だと思ったポイントを整理しておきます。

本書のひとこと概要

Web サービスを「どう Web らしく構築するか」という視点で理論と設計手法を体系化した一冊です。作法や制約を理解することで、安定した設計と運用につながることがよく伝わってきました。

特に重要だと感じた章をピックアップ

第 3 章 REST —— Web のアーキテクチャスタイル

Web がこれほど成功した背景には、REST によって共通の「作法」が育まれたことがあると説明されており、以下のような制約を踏まえることで、拡張性と疎結合を両立できる仕組みが成立しています。

  • リソース: Web 上の情報にはすべて URI という「名前」があり、プログラムからアクセスするための共通言語になっています。
  • クライアント／サーバ: UI とデータ処理を分離することで、お互いの変更を意識しなくてもよくなり、開発チームや技術基盤の分離もしやすくなります。
  • ステートレス性: サーバは過去の会話を記憶せず、1 回のリクエストに必要な情報を全て含むため、スケールしやすいです。
  • キャッシュ: 一度得た情報を再利用することで通信負荷を抑え、パフォーマンス向上にも貢献します。
  • 統一インタフェース: 操作を GET・POST・PUT・DELETE などに限定することで、クライアントとサーバが内部実装を気にせずやり取りできる仕組みになります。
  • 階層化システム: プロキシや負荷分散機を間に挟むことで、複数の層に分けて負荷分散やセキュリティ対策が取りやすくなります。
  • コードオンデマンド: ブラウザにコードを配信して実行させることで、より動的な UI を提供できます。

第 5 章 URI の設計

「クールな URI は変わらない」という原則が、ハイパーメディアとしての Web を支える土台です。

  • 実装依存を排除する: .php や .pl のような拡張子、メソッド名、セッション ID を URI に含めないことで、裏側の技術が変わってもリンクが切れません。
  • 名詞で構成する: URI はリソースの「名前」にあたるため、動詞を含めずに設計するのがベストプラクティスです。

第 7 章 HTTP メソッド

HTTP メソッドは、リソースに対する CRUD 操作を標準化した器です。安全性やべき等性などの特性を理解しながら使い分けることが、頑健な設計につながります。

1. 実質的に利用する 6 つのメソッド

メソッド 役割
GET 取得
POST 作成
PUT 更新 / 作成
DELETE 削除
HEAD ヘッダのみ取得（GET のボディなし）
OPTIONS 利用可能なメソッドを確認

2. Create（作成）の使い分け

  • POST（サーバが URI を決定）: サーバが新しいリソースの URI を自動で割り当てるケース（例: ブログ記事の新規投稿）です。
  • PUT（クライアントが URI を決定）: クライアントが既に URI を知っていたり、自分で決めたりするケース（例: Wiki のページ作成）です。
  • 指針: 理由がない限り、URI の管理がしやすい POST に任せるのが安心です。

3. 安全性・べき等性との関係

  • Read（GET）は「安全」です。リソースを壊さないため何度リクエストしても問題ありません。
  • Update / Delete（PUT / DELETE）は「べき等」です。通信トラブルでリトライしても副作用が発生しないので、クライアントは安心して再送できます。
  • Create（POST）は「べき等ではない」です。二重送信で同じデータが複数作られる可能性があるため、慎重に扱う必要があります。

第 8 章 ステータスコード

クライアントとサーバを疎結合に保つために、ステータスコードは非常に重要な約束事です。1xx〜5xx に分かれた階層を使い分けることで、クライアントは先頭の数字だけで「成功系かエラー系か」を大雑把に判断できます。

  • 1xx（情報）: 処理が継続中であることを示すコードで、リクエストがまだ完了していないことを伝えます。
  • 2xx（成功）: リクエストが正常に処理されたことを示すコードです。
  • 3xx（リダイレクト）: 別の URI に移動したことを示し、クライアントを適切な場所へ誘導します。
  • 4xx（クライアントエラー）: クライアント側のリクエストに問題があるときのコードです。
  • 5xx（サーバエラー）: サーバ側の障害や例外で処理できなかったことを示します。

よく使われるステータスコード

  • 201 Created: リソースの作成に成功したことを示し、Location ヘッダで新しい URI を伝えます。
  • 301 Moved Permanently: リソースを恒久的に移動したことを伝え、古い URI から新しい URI へ自動転送します。
  • 303 See Other: POST の処理後に結果を GET で再取得して二重投稿を防ぐ際に使います。

第 9 章 HTTP ヘッダ

HTTP ヘッダは、ボディ（データ本体）に付随するメタデータを表現します。
クライアントやサーバは、このヘッダを見ることで「このデータをどう扱うべきか」という具体的な挙動を決定します。

1. コンテントネゴシエーション

同じ URI であっても、クライアントの環境に合わせて最適な表現をサーバと交渉する仕組みです。

  • Accept: クライアントが処理できるメディアタイプ（JSON, HTML など）を伝えます。
  • Accept-Language: クライアントが理解できる言語を伝えます。 これにより、一つのリソースに対して、ブラウザには HTML を、プログラムには JSON をといった**「柔軟な出し分け」**が可能になります。

2. キャッシュの制御

一度取得したリソースを再利用することで、通信量と処理時間を減らす仕組みです。

  • Cache-Control: 「どれくらいの期間キャッシュして良いか」を相対的な時間で細かく指定します。
  • 条件付き GET（ETag / If-None-Match）: リソースに「指紋（ETag）」を付与し、変更がない場合は 304 Not Modified でボディの転送をスキップします。これはネットワーク帯域の節約に極めて有効です。

3. 認証ヘッダ

認証ヘッダについては、Authorization ヘッダー - HTTP | MDN から情報を得ました。

  • Authorization (クライアント → サーバ): クライアントが自身の認証情報（資格情報）をサーバに伝えるために利用します。
  • HTTP は**ステートレス（サーバが状態を持たない）**なため、一度ログインすれば終わりではなく、原則としてリクエストのたびにこの認証ヘッダを送信する必要があります。これにより、サーバは過去の通信を覚えておかなくても、その都度アクセスを認可できるのです。

第 15〜17 章 Web サービスの設計

設計の核心は「Web サービスと Web API を分けて考えない」こと

  • リソース指向アーキテクチャ: 「画面（UI）」ではなく、まずシステムで扱う「データ」を特定し、それを「リソース」として切り出し、URI で名前を付けるという手順で設計を進めます
  • リソースをリンクで結ぶ: 各リソースをバラバラに存在するデータとするのではなく、リンク（ハイパーメディア）によって互いに結び付けることで、一連のアプリケーションとしての導線（接続性）を確保します。
  • 多角的な導出: リソースは、データベースの ER 図（関係モデル）やプログラムのクラス図（オブジェクト指向モデル）、あるいはサイトの「パンくずリスト（情報アーキテクチャ）」といった様々な切り口から導き出すことができます

まとめ

2010 年当時の記述で古い部分もあったため、開発者向けのウェブ技術 | MDN と併読しながら補って理解を深めました。
それでも 2026 年現在においても本書の多くの考え方が色あせておらず、Web というアーキテクチャが優れていることを改めて実感しました。
本書で紹介された様々な技術が Web を支えていることを理解しながら、これからの開発に活かしていきたいと思います！

Discussion