書籍

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

作者: 山本陽平
出版社/メーカー: 技術評論社
発売日: 2010/04/08
メディア: 単行本（ソフトカバー）
購入: 143人クリック: 4,320回
この商品を含むブログ (183件) を見る

TL;DR

Webについての概要、基本的な技術(HTTP、URI、HTML)について良く纏まっている。オススメされている本だけある。
Webサービスの設計の流れ、勘所も書かれており、Webサービス設計のイメージが湧く。

この本を選んだ理由

Webの最新技術に興味はあり独学中であるが、根底にある基本的な技術について知識が乏しいと感じていたから。
この本がWebに関する基礎知識を学ぶ上でとても評判が高い為。

印象に残った点

Webについての概要(基礎/歴史/標準化/アーキテクチャスタイルなど)が良くまとまっている

Webを支えるのは3つの基本的な技術(HTTP、URI、HTML)
- 上記3点についてもかなり章を割いて説明されている。
RESTは大学院生(Roy Fielding)が考え博士論文として提出した
- 博士論文がここまで世にインパクトを与えたなんて化け物や...。しかもSOAPという巨大な企業ベースの仕様に打ち勝った。歴史に名を残すんだろうなぁ。
RESTはアーキテクチャスタイルであり、クライアント/サーバアーキテクチャスタイルに制約を加えたもの
- 抽象度はアーキテクチャスタイル(例:REST)>アーキテクチャ(例:ブラウザ)>実装(例:Firefox)
- 追加する制約はステートレス+キャッシュ+統一インターフェース+階層化システム+コードオンデマンド

URIの良い設計(=クールURI)や設計テクニックについて書かれている

変わらないURIこそが最上のURIである。
プログラミング言語に依存した拡張子やパスを含めない、メソッド名やセッションIDを含めない、リソースを表現する名詞にする、という教訓を意識すると良い。
- クールなURIがどういうものか初めて理解できた。これからURIの見方が変わると思う。
設計テクニックとしては拡張子で表現したり(例:言語指定)、マトリクスURI(スラッシュを使った階層化)を使う。
複数パラメータの組み合わせであれば、セミコロンやカンマを使う。セミコロンの場合は順不同、カンマは順序に意味がある。
- セミコロンとカンマの違い知らなかった。

HTTPメソッドの種類や役割、性質について記載されている

8つメソッドがあるがTRACEとCONNECTはよほど使わない。
【GET】最も利用頻度が高く、リソースを取得するメソッド。
【POST】GETの次に利用頻度が高く、子リソースの作成、リソースへのデータ追加、他のメソッドでは対応できない処理(例:URIにキーワードを含めてGETしたいが、キーワードが長すぎる場合にPOSTのボディにキーワードを定義して対応する)の3つの役割がある。
【PUT】リソースの更新、リソースの作成の2つの役割がある。
- POSTとPUTの差はリソースのURIをクライアントが決めるか否かになる。PUTだとサーバ側の仕様をクライアントが把握することになり結合が密になる。
  - なるほどー!やっとPOSTとPUTの違いがクリアになった。
【DELETE】リソースを削除する役割があり、一般的にレスポンスにボディを持たない。
【HEAD】ヘッダ(メタデータ)のみを取得し、一般的にレスポンスにボディを持たない。
【OPTIONS】リソースがサポートしているメソッド一覧を返す。返す際はAllowヘッダを使う。
POSTでPUTやDELETEを代用することがある。
- HTMLのフォームにGETとPOSTしか指定できないという背景がある(今はAjaxで用いるXMLHttpRequestを使い任意のメソッドが呼べる)
  - Ruby on Railsが採用している_methodパラメータを使いContent-Typeにapplication/x-www-form-urlencodedを指定する方もある。
  - application/x-www-form-urlencodedが利用できない場合はX-HTTP-Method-Overrideヘッダを利用する。
    - そんな背景があったのか。知らなかった。
メソッドにはそれぞれ性質がある。
- GET/HEADは冪等性かつ安全、PUT/DELETEは冪等性だが安全ではない、POSTは冪等でも安全でもない
  - PUTとPOSTの違いを表す際に冪等か否かも判断理由になることが分かり、また理解を深めることができた。

Webサービスの設計について書かれている

リソース指向アーキテクチャのプロセスが書かれている。
- ①Webサービスで提供するデータを特定する
- ②データをリソースに分ける
- ③リソースにURIで名前をつける
- ④クライアントに提供するリソースの表現を設計する
- ⑤リンクとフォームを利用してリソース同士を結び付ける
- ⑥イベントの標準的なコースを検討する
- ⑦エラーについて検討する
リソースの更新は基本的にはPUT、バッチ処理はPOSTで行う
- バッチをPOSTにする理由はPUTだとURIの指定をしないといけないから。
- サーバ側でパーシャルアップデートをサポートする場合は通常バルクアップデートもサポートする
  - そうなんだー。こういう情報ありがたい。
バッチ処理のレスポンスはトランザクション化するもしくはどこまで成功したかを送るパターンもある(例:「207 Multi-Status」「D:multistatus」の組み合わせ)
- トランザクション化が一般的かと思っていたがどこまで成功したかを返すこともあるんだ。クライアントにぶん投げてクライアントが頑張るのかな。
- トランザクションをRESTfulで実装する際はトランザクションリソースを使う。
  - RESTfulな設計の定石として新たなリソースを導入して解決する。ほぇ～。そもそもトランザクションリソースという考えには至らなかったし、こういう新しいリソースを足して解決するのが定石なのかぁー。
- トランザクションの開始(POST)、処理対象の追加(PUT)、実行(PUT)、リソース削除(DELETE)の手順を取る
  - 結構手間かかるんだなぁ。こりゃ大変だ。
- バッチ処理としてPOSTで一括化し、サーバ側で処理を保証する方法もある
  - なるほどねぇ～。育ってきた環境なのかサーバ側のほうがしっくりくるなぁ。
サービス設計はトレードオフ。なるべくシンプルに保つ、困ったらリソースに戻って考える、本当に必要ならPOSTで何でもできるがコツ。
- なるほど～。POSTに頼りすぎないようにしなくては。

リソース設計のコツが書かれている。

リソース設計は名前(URI)を与えるのが非常に難しい
- 既存の設計手法である関係モデルのER図、オブジェクト指向モデルのクラス図、情報アーキテクチャを併用すると良い
  - Webサービスの設計にも既存設計手法は使えるのか!
- ER図からのリソース導出は、下記のポイントで行う。
  - 中心となるテーブルの一行をリソースとして切り出し、主キーをリソースのURIにする。
  - リソースが持つデータの特定は外部キーで参照している別テーブルの属性も集約する(あえて正規化をクズす)。これはリソース自身で全てを表現できるように自己記述的にするため。
  - ER図から階層構造はなかなか分からないので、別途ドキュメントなどから理解する必要がある。
  - ER図からトップレベルリソースは直接導出できない。
  - リソース間のリンクはER図の関連がヒントになる。
- オブジェクト指向モデルからの導出は下記のポイントで行う。
  - 主要となるデータを表現しているクラスのインスタンスがURIを持つリソースになる。
  - クラスの持つメソッドから操作結果リソースの導出が可能。
  - 1対nのhas-a関係はリソースの階層構造に反映できる。is-a関係や継承関係も階層構造化できる可能性があるのでその点も確認する。
  - クラス図からトップレベルリソースを直接表現できない。
  - リソース間のリンクはオブジェクトの参照をそのまま表現できる
- 情報アーキテクチャはわかりやすさのためのデザイン(表現技術)であり、Webデザインでいうと、ユーザー操作やページ遷移などを整理して受け手にとって情報を探しやすく、分かりやすく伝えるための技術。
  - よく設計された情報アーキテクチャを持つWebサイトの構造はリソースのリンク関係に適用できる
色々と書いたがリソース設計で大事なのはWebサービスとWebAPIを分けて考えないこと！

今後

少し昔の本なので得られた知識を更新する必要がある。今の技術動向を常にWatchし、知識のアップデートをしていきたい。

余談

セマンティックWeb(RDF/microformatsなど)やAtom/Atom Publishing Protocolを話題としてみかけないなぁ。
- 情報感度が足りていないのか、時代が進むにつれてあまり話題にならなくなったのか…。調べて見る限り後者のような気がしている。
JSONの日付けはタイムゾーン意識したISO8601使うとのこと。
- 医療機器でISO8601のIFを持ってる機種はあまりみかけないなぁ。ええんかしゃん。