はじめに

ついさっきWEB+DB PRESS plus『Webを支える技術』を読了したので、備忘録を書きました。
本書はWeb概論、URI、HTTP、ハイパーメディア、設計Tipsの五部立てになっているんですが、URIとHTTPについてはメモが欠落していたため転写できませんでした。ご容赦ください。
自分のような新人エンジニアの学習の取っ掛かりや、忙しい人の知識の確認リストにでもなれば幸いです。

1部.Web概要

webの重要な特徴は、ハイパーメディアと分散システム
- ハイパーメディア：テキスト、画像、音声、動画などのマルチメディアをリンクで結びつけて構成されたシステム。ユーザーが能動的にリンクを選択して、ある情報から他の情報へと非線形に情報を参照・取得していく。
  - Webはインターネットを用いたハイパーメディアで、不特定多数の情報をリンクさせ合うことができる。
  - Webのリンクは単方向リンクで、シンプルな構造なのが特徴
- 分散システム：複数のコンピュータを組み合わせて処理を行うシステム。これに対して１つの中央コンピュータがすべての処理を行うのを集中システムと呼ぶ。
  - Webは、世界中のクライアントが世界中のサーバーにアクセスできる非常に大規模な分散システムだと言える。これは通信プロトコルをシンプルなHTTPで統一することで実現している
基盤技術はHTTP, URI, HTMLの3つ
- HTTP：Hyper Text Transfer Protcolの略で、リクエストとレスポンスが対になったWebにおける情報通信のルール。TCP/IP階層モデルに基づいている。
  - 基本メソッドは8つのみ。中でもGET, POST, PUT, DELETEが頻出
  - 後述のRESTの大半に大きく関わっており、3つの中でも根幹技術と言える
- URI：Uniform Resource Identifierの略で、インターネット上のリソース（情報）を一意に識別するためのモノ。主に以下の要素からなる
  - URIスキーム：そのURIが用いる通信プロトコルを示す
  - ホスト名：そのリソースのインターネット上の所在地。DNS（Domain Name System）で名前解決できるドメイン名かIPアドレスが入る
  - パス：そのリソースのホスト内の所在地を示す。ファイルシステムと同じ様に階層表記する
- HTML：Hyper Text Markup Languageの略で、XMLに基づく汎用文書フォーマット。URIに示された実際の情報の表現を規定する

REST

Webについてのアーキテクチャスタイル（複数のアーキテクチャに共通する性質・様式）で、以下６つのアーキテクチャスタイルから成る
このスタイルに沿ったWebサービスやWeb APIをRESTfulと呼ぶ。

クライアント・サーバ：UIと、処理やデータストレージを分離するアーキテクチャスタイル（以下C/Sと表記）
- サーバはデータを扱うだけで良いので、クライアントをマルチプラットフォームにできる（PC、携帯、ゲーム機を問わずアクセス可能）
- サーバの冗長化による可用性上昇が可能
ステートレス：サーバ側で、クライアントのアプリケーション状態（別名をセッション状態：ログインしてからログアウトするまでの操作の状態）を記憶しないというアーキテクチャスタイル
- サーバーサイドの実装が簡単
- ステートフルだと、複数のサーバでクライアントの状態を同期しなければならず、そのオーバーヘッドのせいでユーザーが増えるとスケールアウトしにくいが、ステートレスだとクライアントが毎回必要な情報をすべて送ってくれるので、ユーザーが増えても単にサーバを増設すれば良い
- これに沿わない実装もある
  - ex.Cookie：SからCに発行する、セッション状態を記録したテキストデータ。C側に保存され、次回以降のアクセスの際にこれを用いることで、すでにログインした状態でサイトにアクセスできたり、ECショップであればカート商品がそのまま残っていたりと、利便性が上がる
キャッシュ：一定の期間、一度サーバから取得したリソースをクライアント側に保存して使い回すアーキテクチャスタイル
- 最近のデータをローカルに保存しておくことで、同じサイトにアクセスしたときの通信量を削減できる。Cookieとは別物
統一インターフェース：HTTPメソッドのように、統一された限定的なインターフェースでリソース操作を行うアーキテクチャスタイル
- Webのシンプルさの肝
- 統一インターフェースに準じることで、システム全体を多層化しやすくなる(5番につながる)
階層化システム：システムを、単なるクライアント・サーバ以上の複数の階層に分離するアーキテクチャスタイル
- C/S間にプロキシでアクセス制限を設けたり、Webサーバをレガシーな基幹システムのインターフェースとして設置してクライアントブラウザと接続させられる
コードオンデマンド：サーバからダウンロードしたコードをクライアント側で実行するアーキテクチャスタイル
- Flash, Javascriptなどが具体例

REST以外の代表的なアーキテクチャスタイルにP2Pがある。これは、サーバを介さない各個コンピュータどうしの通信に関するもの

筆者いわくWebの成功要因は、シンプルな技術を土台に適切な制約を積み重ねていったこと。これらによって複雑さが抑えられ、大規模化を可能にした。

4部.ハイパーメディアフォーマット

URIで指定された各リソースの、実際の表現を規定するのがハイパーメディアフォーマットで、HTMLを筆頭に以下のような種類がある

HTML

タグで文書構造を定義するフォーマットをマークアップ言語とよび、それを用いた文書を構造化文書と呼ぶ。XMLやHTMLはこの一種。
マークアップ言語としての木構造と、ハイパーメディアとしてのリンク関係を意識して読解する

microformats

HTML内の要素にプログラムが読解可能な付加情報を埋め込むことで、軽量なセマンティックWebを実現しようとする技術
- セマンティックWeb：Web上のリソースに対して（一定の規則に基づいて）メタデータを加えることで、そのリソースを、人間が読んで意味がわかるだけでなく、プログラムからも処理しやすくしようという考え方
主にaタグやlinkタグに対してメタ情報を埋め込んでいくだけなので、従来のRDFのようなものより扱いやすい
Webページをプログラムから直接扱えるようにする技術、という意味で、microformatsはWebページをWeb APIとしてそのまま提供する技術、と捉えることもできる

JSON（JavaScript Object Notation）

XML系のリソース表現に比べて軽量で、ハッシュテーブル（Key:Value表現のこと）、配列といったプログラミング言語から扱いやすい形のデータ構造を記述できる
関連用語
- オブジェクト：JSONフォーマットにおける組み込みのデータ型で、名前と値のペアが複数集まったものを指す。
- メンバ：オブジェクト内の、個々の名前と値のペアのこと。名前は文字列型、値はJSONで定義されていればどんな型でもOK
- リテラル：ソースコードに直接記述する、変数や定数以外の値のこと
- Ajax：Asynchronous JavaScript + XMLの略で、サーバーとの非同期通信を行うための、JavaScriptとXMLを用いた実装方式
  - 同期通信：リクエスト送信後、サーバからのレスポンスを待って次の処理を行う通信方式
  - 非同期通信：リクエスト送信後、サーバからのレスポンスを待たずにクライアント側で処理を進めることができる通信方式
  - JavaScriptと、その組み込みAPIであるXMLHttpRequestを用いることで、非同期通信でサーバにリクエストを送信できる。そのレスポンスをクライアント側で反映する際に、DOMを用いて部分的に変更箇所を指定することで、画面遷移を行わずにページの状態を更新していくことができる
- JSONP（JSON with Padding）：クロスドメイン通信を実装する手法
  - 不特定多数のドメインに属するサーバにアクセスすることをクロスドメイン通信と呼ぶが、Ajaxで使うXMLHttpRequestは、基本的にクロスドメイン通信を許可しない。つまり、JavaScriptファイルを取得したサーバとしか通信を許可しない。（別のサーバと通信できてしまうと、ユーザーが入力した情報を不正に他のサーバへ送信する、といったWebサイトを作れてしまうため）
  - しかし、他のWeb APIから非同期に情報を取ってくる事ができないのは大きな制約である。その代替手段として、HTMLのscript要素を使えば複数のドメインからJSを読み込むことができる。これを用いてクロスドメイン通信を行うのがJSONP
  - 具体的な手法は本書p238, 239。コールバック関数を活用する？

5部.Webサービス設計Tips（特にリソース設計）

サービスの性質として筆者が重要視するものがアドレス可能性、接続性、統一インターフェース
- アドレス可能性：URIでリソースを一意に指定できる性質。最重要
- 接続性：サービス内でリソースがリンクによって繋がっていること
リソース設計：どのようにリソースを提供するかについての設計。つまり、Webサービス、Web APIの外部設計（クライアントとの接点の設計）
- リソース指向アーキテクチャ：リソース設計の指針の1つ。以下のフローでリソースを設計する
  1. サービスで提供するデータを特定する
  2. データをリソースに分ける
  3. 各リソースにURIで名前付けする
  4. 各リソースの表現を設計する（HTML, XML, JSONなどで見え方を定義）
  5. リンクとフォームを用いてリソースどうしを結びつける
  6. イベントの標準コースを検討
  7. 異常系を検討
書込み可能なサービスを設計したい場合、主に以下の点にも留意する必要がある
- 単純にPOST, PUT, DELETEの実装が必要
- 複数ユーザーの同時書き込みをどう扱うか（排他制御）
- 同時に複数のリソースを更新する手法（バッチ処理）
- 一連の複数の処理を必ず実行するためのセーフティ（トランザクション）
シンプル性を保つこと、リソースベースで考えること、最悪POSTに頼ることを意識しながら設計する

『Webを支える技術』を部分的に要約