Webを支える技術　第1部　Web概論

備忘録です。

## 第1章 Webとは何か

- さまざまなWebの用途
    - Webサイト
    - ユーザインタフェースとしてのWeb
        - 各デバイスの設定画面
        - HTMLのヘルプ記述
    - プログラム用APIとしてのWeb
- Webを支える技術
    - HTTP、URI、HTML
    - ハイパーメディア
        - テキストや画像、音声、映像などの様々なメディアをハイパーリンクで結び付けて構成したシステム
        - 書籍や映画などとは対照的に非線形的にユーザーが自分でリンクを選択して情報を取得する
    - 分散システム
        - 複数のコンピュータを組み合わせて処理を分散する形式
        - Webは世界中に配置されたサーバに世界中のブラウザがアクセスする分散システム
            - プロトコルのシンプルさによって、この規模のシステムが実現している
            
## 第2章 Webの歴史

- Web以前のインターネット
    - 起源はARPANET（1969）
    - 米国内の大学や研究機関の間を（当時としては）高速な回線で接続し、全米を繋ぐネットワークとして徐々に成長
- Web以前のハイパーメディア
    - 問題点
        - 全体としてシステムの複雑さがネックで普及しなかった
    - Memex
        - 情報検索システムについての論文（1945）
    - Xanadu
        - ハイパーテキスト/メディアの考案
        - 開発自体はその複雑さ故に頓挫した
    - HyperCard
        - スクリプト言語HyperTalkによるプログラムを実行できる、スタンドアローンWebサービス
- Web以前の分散システム
    - 問題点
        - 性能劣化
            - ネットワーク越しの関数呼び出しは時間がかかり、さらに目的を達成するために何度も関数を呼び出さなければならない（ネットワークオーバーヘッドの問題）
        - データ型変換
            - 複数の言語が混在する環境で問題が生じる
        - インターフェースバージョンアップ時の互換性
            - 機能追加などの更新によって古いクライアントの下位互換性がなくなる
        - 負荷分散
            - サーバにクライアントのアプリケーション状態を保存する
            - 上記情報をサーバ間で共有するのが難しい
    - RPC
        - Remote Procedure Call
        - リモートのサーバで実行しているプログラムをクライアントから呼び出せる
        - SunRPC（ONC RPC）、アポロ、DCE
    - 分散オブジェクト
        - 関数呼び出しではなくオブジェクト自体をリモート側に配置する分散オブジェクトという技術が考案された
        - CORBA、DCOM
- Webの誕生
    - ハイパーメディアを用いたインターネットベースの分散管理システムとしてWebの提案書が書かれ、すぐにブラウザとサーバが実装された（Tim Berners-Lee）
    - その後ブラウザMosaicが公開され、Webの普及を一気に推し進めた
- ハイパーメディアとしてのWeb
    - インターネットを使ったハイパーメディアとして設計されたため、インターネットを用いている不特定多数の情報をリンクさせ合う事ができ、システムを大規模化しやすい
    - 情報の集中管理が難しく、リンク切れを起こしやすいという欠点もある
- 分散システムとしてのWeb
    - オープンなネットワーク環境で不特定多数のクライアントに対してサービスを提供するシステムとして向いている
- Webの標準化
    - Webの普及があまりに急速で、IETFでの仕様策定が追いつかず、相互運用性に欠ける状態が発生していた
    - Berners-Leeを中心としてW3Cで標準化作業が行われた
- RESTの誕生
    - HTTPの仕様策定をしていたFieldingが、Webの成功要因をソフトウェアアーキテクチャの観点から分析し、RESTというアーキテクチャスタイルとして博士論文にまとめた
- さまざまなハイパーメディアフォーマットの誕生
    - microformats
        - HTMLの構造はそのままに、HTMLにさまざまな意味を持たせる技術
    - RSS
        - RDF Site Summary, Rich Site Summary, Really Simple Syndication
        - Webページの新着情報をサーバで配信し、専用のプログラムでそれをチェックする
    - Atom
        - RSSの標準化
    - JSON
        - XMLではデータを記述するのに表記が冗長なので、提案されたより単純なデータフォーマット
- WebAPIをめぐる議論
    - SOAP
        - HTTPをトランスポートプロトコルとして扱い、HTTP上で独自のメッセージを転送する
        - 転送方法だけ定めた仕様
    - WS-*
        - SOAP上にサービスごとの統一したプロトコルを定義するための周辺仕様群
    - 当初、SOAPは大手ベンダーによって推進されたが、その簡潔さからRESTに軍配が上がった
        - SOAPとWS-*の敗因としては
            - RPC/分散オブジェクトが持っていた課題を継承し複雑な使用群にしてしまった
            - ベンダー同士の政治的な理由が原因で相互運用性に欠けていた

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

- アーキテクチャスタイル
    - MVC、パイプ＆フィルタ、イベントシステムなど
    - マイクロアーキテクチャパターンではない（クラスなどの設計様式ではない）
    - RESTはネットワークシステムのアーキテクチャスタイル
        - 例）クライアント/サーバー
        - ちなみにRESTはクライアント/サーバーから派生したもの

| 抽象化レベル | Webでの例 |
| --- | --- |
| アーキテクチャスタイル | REST |
| アーキテクチャ | ブラウザ、サーバー、プロキシ、HTTP、URI、HTML |
| 実装 | Apache、Firefox、Internet Explorer |
- リソース
    - Web上に存在する、名前を持った亜利とあらゆる情報のこと
    - リソースは名前（URI）を持つ
    - URIを用いて、プログラムはリソースが表現する情報にアクセスできる
    - サーバー/クライアント間でやり取りするデータをリソースの表現という
        - HTML形式、テキスト形式、PDF…
        - リソースの状態によって表現は変化する
- アドレス可能性
    - URIが備える、リソースを簡単に指し示せる性質
- RESTアーキテクチャスタイルの構成
    - クライアント/サーバー
        - HTTPプロトコルでクライアントとサーバーが通信する
        - 単一のコンピューター上での処理ではなく、クライアントとサーバーに分離できるのが利点
            - クライアントをマルチプラットフォームにできる
            - 複数のサーバーを組み合わせて冗長化し、可用性を上げられる
    - ステートレスサーバー
        - クライアントのアプリケーション状態をサーバーで管理しない（リクエストごとに全ての情報を送信する）
            - サーバー実装の簡略化ができる
        - Cookieを使ったセッション管理はステートフルな実装でREST的には誤り
    - キャッシュ
        - 一度取得したリソースをクライアント側で使い回す方式
            - 通信を減らしてネットワーク帯域の利用や処理時間を縮小し、より効率的に処理できる
            - 古いキャッシュを利用して情報の信頼性が下がる可能性もある
    - 統一インターフェース
        - URIで指し示したリソースに対する操作を統一した限定的インターフェースで行う
            - インターフェースを統一することで、クライアント/サーバーの実装の独立性が向上する
        - 例えば、HTTP1.1では、GETやPOSTなど8つのメソッドに限定している
    - 階層化システム
        - システムをいくつかの階層に分離するアーキテクチャスタイル
        - 例えば、サーバーとクライアントの間にロードバランサやプロキシを設置したり、レガシーシステムの前にWebアプリケーションサーバーを挟んだりするイメージ
    - コードオンデマンド
        - プログラムコードをサーバーからダウンロードして、クライアント側で実行するアーキテクチャスタイル
            - クライアントを後から拡張できる
            - ネットワーク通信におけるプロトコルの可視性が落ちる
                - 通信の意味やアクセスリソースが曖昧になる
        - JavaScript, Flash, Javaアプレット
- アプリケーション状態エンジン
    - RESTはアプリケーション状態エンジンとしてのハイパーメディア
    - アプリケーション状態とは、ブックマークの一覧表示をしている、新しいブックマークを追加しようとしている、など
    - ハイパーメディアのリンクを辿る作業でアプリケーション状態が遷移する
- RESTと分散システム
    - RPC,CORBA,DCOMなどの分散オブジェクトは、関数やメソッド単位でサーバ側の処理を呼び出すのでオーバーヘッドが大きく、機能追加でAPI互換性が失われるという問題がある
    - 一方RESTに基づいた設計では、リンクを辿ることでアプリケーションを実現するので、性能劣化を抑えられ、統一インターフェースの恩恵で互換性の問題は生じない