# Webを支える技術　第１部　Web概論
## 第1章 Webとは何か
### 様々なWebの用途
* Webサイト：各種サイト
* UIとしてのWeb：家電製品などの設定を、ブラウザ操作で行うためのサイト
* プログラム用APIとしてのWeb：XMLやJSON等
### Webを支える技術
* HTML, URI, HTTP：解説はプロになるためのWeb技術入門のページを参照。
* **ハイパーメディア**：メディアをハイパーリンクで結び付けて構成したシステムのこと。
* **分散システム**：複数のコンピュータに処理を分散し、効率を上げたシステム。プロトコルがシンプルである。

## 第2章　Webの歴史
### 2.1 Web以前のインターネット
インターネットの起源は1969年に構築されたARPANETで、米国内の大学や研究機関をネットワークで結んだ。
メール送信はTCP/IPのほかに、バケツリレー方式のUUCP(UNIX to UNIX Protocol)による転送も生じたため、到着するまで遅延があった。
インターネットアプリが盛況に。（電子メール、ネットニュース、telnet等）
### 2.2 Web以前のハイパーメディア
ハイパーメディアは1945年にMemexが論文で発見され、インターネットよりも歴史は古い。
Web以前に成功をおさめたハイパーメディアとして、**HyperCard**がある。
カードと呼ばれる文書を単位に相互にリンクを張り、スクリプトを実行できるスタンドアロンのWebサービスである。多くの企業で採用され、Web以前の実用的な形として用いられた。
こうしたハイパーメディアには、以下のような問題点がある。
* 単方向リンクしかサポートしていない
* リンクが切れる可能性がある.
* バージョン管理やトランスクルージョン（埋め込み）ができない。

### 2.3 Web以前の分散システム
#### 集中システムと分散システム
当時の大型PC（メインフレームなど）の場合は、**ホストコンピューターで集中的に管理**していた。コンピューターが小型化し性能が向上すると、**複数サーバが組み合わせ処理**を行い、**全体のスループットの向上（全体最適化）** を図るようになった。
#### RPC(Remote Procedure Call)
**リモートで他のサーバを呼び出す技術**である。サーバ同士あるいはクライアントからサーバへの接続が可能となり、分散システム発展への第一歩となった。
（例）：SunRPC, DCE等　→UNIX戦争時代(1980年代後半)の産物
#### CORBA,DCOM
単なる関数呼び出しではなく、オ**ブジェクト自体をリモート側に配置する「分散オブジェクト」** の代表例。
CORBAやDCOMは、IDL(Interface definition launch)でオブジェクトの定義を取得して、実装時にネットワーク越しにシリアライズしたメッセージを交換する。
なお、CORBAとDCOMは双方のシステムが接続できない。
#### RPCの問題点
* **性能劣化**：ネットワーク越しの関数呼び出しは同一プロセス内での呼び出しに比べて何倍もの時間がかかる。
* **データ型変換の問題**：言語ごとにデータ型の定義が異なるため、データ型の変換時に問題が発生する。
* **負荷分散の問題**：RPCでは、サーバ上にクライアントのアプリケーション状態を保存するため、多数のサーバでの負荷分散が難しい。

### 2.4 Webの誕生
Webは1990年のCERN（欧州原子核研究機構）のBerners-Lee氏がシステムの一部としてWebを用いた提案書を書いたのが始まりで、同年12月に最初のバージョンのブラウザとサーバを完成させた。
さらに1993年には、イリノイ大学のNCSA（米国立スーパーコンピューター応用研究所）がMosaicというブラウザを発表した。
以降これをベースにインターネットブラウザが立ち上がっていくことになる。

#### ハイパーメディア・分散システムとしてのWeb
Webとハイパーメディアを比べると、Webに対し以下のようなメリット・デメリットがある。
* **不特定多数の情報をリンクできる。**
* **システムを大規模化しやすい。**
* **単方向リンクのみでシンプル。**
* **リンク切れしやすい。**

一方で、Webと分散システムを比べると、Webに対し以下のようなメリットがある。
* **オープンで不特定多数を相手にする。**
* **デバイスに依存せず利用できる。**
* **世界中の人々が利用できる。**

### 2.5 Webの標準化
#### 2.5.1 Webの仕様策定
Webでの通信技術（URI、HTTP、HTML）は、**標準化**が求められるようになった。
1994年にこれらの標準化を行う団体として**W3C（World Wide Web Consotium）** が設立された。
中でもHTMLとCSSは、IEとNetscape Navigatorの**相次ぐ独自拡張が問題視**されていた。現在もIEでしか閲覧不可のサイトも残っている。
Berners-LeeはWebのコンセプトから初期実装までの大役を担ったが、Webの礎を完全に築いたとはいえない。

#### 2.5.2 RESTの誕生
**REST(Reprisentational State Transfer)は、Roy Fielding氏**によってまとめられたアーキテクチャスタイルである。これまでのWebの成功から、大規模システム成立の謎まで、ソフトウェアアーキテクチャの観点で分析が行われている。Fielding氏は、HTTPはハイパーテキストの転送以外にも、**リソース状態の表現**を行っていると主張している。

#### 2.5.3 様々なハイパーメディアフォーマット
HTMLが唯一のハイパーメディアフォーマットであったが、様々な要望に応えるハイパーメディアフォーマットが開発された。microformatsや、RSSといった開発の末、**デファクトスタンダードとなったのがJSONであった。**

### 2.6 WebAPIを巡る議論
1990年代後半から2000年代前半にかけて、プログラムの自動処理を行うAPIの要望が強まり、様々なAPIが開発された。
#### 2.6.1 SOAPとWS-*
SOAPは、以前から開発が活発なRPC・分散オブジェクトの分野の最も基本的なプロトコルである。HTTPをアプリケーションプロトコルではなく、トランスポートプロトコルとして扱う。MicrosoftがW3Cに提案し、標準化が始まった。
また、SOAP上のサービスごとのプロトコルとして、WS-で始まる周辺仕様群が次々と提案された。これらをまとめてWS-* と表す。開発競争が起き、標準化は困難を極めた。
#### 2.6.2 SOAP VS REST
SOAPとWS-* を巡る混乱の中、殴り込みをかけてきたのはRESTを主張するFinding氏であった。最初は名だたる大手ベンダーの壁にぶつかるも、徐々に主張を支持するW3Cメンバーも現れ始めた。
分散オブジェクト技術者のMark Bakerと、XML及び構造化文書技術者のPaul Prescod両氏は、Webを通じてRESTに出会い、RESTの良さを主張するようになった。

#### 2.6.3 AWSの登場とRESTの誤解と普及
RESTの運命を変えたのが、米アマゾンのクラウドサービスAWSだった。同サービスでSOAPとRESTの利用比率を調べたところ、SOAP20%, REST80%という結果が出たのである。
これに猛反発したのはSOAP主張陣営。セキュリティの緩さやトランザクション処理の未熟さを批判した。「RESTはおもちゃだ」という、旧来のエンジニアからの侮蔑が込められた発言もあったという。
しかし、2004年のWeb2.0の目玉となったマッシュアップ機能でRESTの手軽さが支持され、勝負あり。激しい論争にRESTが打ち勝ったのである。

#### 2.6.4 SOAP陣営が負けた理由
SOAPとWS-* は、以下の理由で敗れてしまった。
* RPC・分散オブジェクトの問題点をそのまま継承してさらに複雑化しているという技術的要因
* SOAPとWS-* の標準化作業は、各ベンダーがドラフトを持ち寄って差異を調整する形で行われたが、独自部分が多く相互運用性に欠けてしまったという政治的要因

### 2.7 すべてがWebへ
RESTの普及と時を同じくして、Webも瞬く間に普及していった。
これにはAjaxやComet等の技術的進歩が大きくかかわっている。
Webの重要性は増すばかりである。

## 第3章　REST　-Webのアーキテクチャスタイル
### 3.1 アーキテクチャスタイルの重要性
**RESTはWebのアーキテクチャスタイルである。**
アーキテクチャスタイル（アーキテクチャパターン）は複数のアーキテクチャに共通する性質や様式等を表したものである。
なお、アーキテクチャスタイルは特定の実装やアーキテクチャではないことに留意が必要。
### 3.2 アーキテクチャスタイルとしてのREST
Webのアーキテクチャスタイルで最も有名な**クライアント／サーバに、いくつかの制約を加えたものがREST**である。
ソフトウェアのコンポーネントが協調して動作するように制約を加えていく。
また、RESTは個別のWebサービスやWebAPIのアーキテクチャスタイルでもある。
### 3.3 リソース
**リソース**とは、Web上の名前を持ったあらゆる情報のことである。
ここでの名前は、個別のリソースを一意に識別できるユニークな名前である必要がある。ここで用いられるのがURIである。
**URIを用いてプログラムはリソースが表現する情報にアクセスできる。** そのため、いちいち自然言語で説明する必要がない。
こうしたURIのリソースを簡単に表せる性質を「**アドレス可能性(Addressability)**」という。
また、同一のリソースを表す複数のURIを作成することも可能である。
リソースとサーバ間でやり取りするデータを**リソースの表現**といい、リソースの状態が変わると表現も変化する。
### 3.4 スタイルを組み合わせてRESTを構成する
RESTは複数のアーキテクチャスタイルを組み合わせて構築した**複合アーキテクチャスタイル**である。
#### 3.4.1 クライアント／サーバ
最も基本となるアーキテクチャスタイルで、クライアントとサーバ間でUIとデータストレージを分割し、リクエスト・レスポンスのやり取りを行う。
#### 3.4.2 ステートレスサーバ
クライアントの**アプリケーション状態を管理しないサーバ**のこと。サーバの簡略化が行える。状態はクッキーで保持する。
クライアント／ステートレスサーバ
#### 3.4.3 キャッシュ
一度取得したデータをリソースの鮮度に基づいて保持し使いまわす方式である。クライアント・サーバ間の**通信を減らし、レスポンスの高速化が図れる。**
クライアント／キャッシュ／ステートレスサーバ
#### 3.4.4 統一インターフェース
URIで指示したリソースに対する操作を、**統一した限定的なインターフェースで行う**アーキテクチャスタイル。
HTTP1.1ではGET, POST, PUT, DELETE等、計8つのインターフェースに限定して通信を行う。
インターフェースの柔軟性に**制限を加える**ことで、全体のアーキテクチャが**シンプル**になる。
#### 3.4.5 階層化システム
システム全体を階層化しやすい統一インターフェースでは、**ロードバランサーの設置による負荷分散**や、**プロキシによるアクセス制限等による階層化**が行える。
統一／階層化／クライアント／キャッシュ／ステートレスサーバ
#### 3.4.6 コードオンデマンド
**コードオンデマンド**は、プログラムコードをサーバからダウンロードし、クライアント側で実行するアーキテクチャスタイルである。
具体例としてはJavaScriptやFlash,Javaアプレット等がある。
**クライアントを後から拡張できる**ため、クライアントプログラムに用意されていない機能を追加できる。
但し、ネットワーク通信におけるプロトコルの可視性が低くなるデメリットがある。
統一／階層化／コードオンデマンド／クライアント／キャッシュ／ステートレスサーバ
#### 3.4.7 REST=ULCODC$SS
RESTの代表系が、以上に挙げた6項目を組み合わせた、ULCODC$SSという複合アーキテクチャである。

### 3.5 RESTの2つの側面
#### 3.5.1 RESTとハイパーメディア
Web上でリソース同士が持つURIをたどりながら、目的のリソースにたどり着く一連の流れを、
「**アプリケーション状態エンジンとしてのハイパーメディア**」という。
利用者が保持する状態は、URIをたどっていく度に遷移するため、アプリケーション状態エンジンと呼ばれる。
利点としては、URIが分かれば、他のアプリケーションでも再利用可能である点が挙げられる。
RESTが基幹とするのは、**リソースをリンクで接続して1つのアプリケーションを構築する「接続性(Connectedness)」の考え方**である。
#### 3.5.2 RESTと分散システム
分散オブジェクトでは関数やメソッド単位でサーバ側の処理を呼び出すが、ネットワーク越しの関数呼び出しはオーバーヘッドが酷く、
呼び出しが多いほどシステム全体の性能劣化を引き起こしてしまう。
一方で、RESTを利用したリンクをたどったアプリケーションの実現は、**リソースを一つのデータとして扱うため、粒度が大きく性能劣化**が抑えられる。
また、統一インターフェースを利用することで**互換性による問題が発生せず**、更新の手間を最小限に抑えられる。

###### tags: `読書`