yohei-y:weblog

XML と REST/Web サービス関連の話題が中心の weblog です

2010-03-03

『Webを支える技術 ── HTTP、URI、HTML、そしてREST』という本を書きました

このブログ、1年近くご無沙汰していました。その間なにをやっていたかというと、実はずっと本を書いていました。『Webを支える技術 ── HTTP、URI、HTML、そしてREST』というなんとも挑戦的な題名の本です。技術評論社さんのWEB+DB PRESS Plusシリーズの11冊目で、来月発売される予定です。

この本は、WEB+DB PRESSで連載していた「RESTレシピ」という連載がベースになっています。実は連載が1年経ったくらいから、技評さんからは書籍化のオファーをもらっていました。ただ、その時点では書いた分量も少ないし、そもそも自分に雑誌記事とは比べ物にならないくらい分量のある本が書けるとは思っていなかったので、書籍ではなく連載継続という形でトータル2年間連載をしました。

ただ、「RESTレシピ」の連載を続けるうちに、少し疑問に思うことが出てきたのです。「RESTレシピ」は基本的にHTTPやURIの知識を前提に、それらをどうRESTfulに使うか、を解説しようと試みた連載です。HTTPとURIはいわば前提知識でした。しかし、その前提知識を得ようとすると、結構大変なことがわかります。

具体的には本書のレビュアをお願いした高橋さん(高橋さんは同時並行していた文字コード本もレビューしていたそうです。さらに最近監訳本も出てるし…凄いですね!)のこのエントリが詳しいですが、HTTP解説本は現在壊滅的な状況です。僕も学んだ『Webプロトコル詳解』も『HTTP詳説』も絶版なのです。僕が2007年に監訳した『RESTful Webサービス』があるのですが、こちらはHTTPやURIを主題に解説しているわけではありません。オライリーにも英語であれば『HTTP Definitive Guide』がありますが、残念ながら日本語訳は出ていません。

幸いなことに日本にはStudying HTTPという素晴らしいサイトがあります。HTTPやURIの詳しい仕様を知ろうと思えば、このサイトで事足りることも多いです。ただし、Studying HTTPさんはあくまでも仕様の解説であり、その仕様をWebサービスの開発においてどのように実践的に使っていくか、という情報はあまりありません。

ということで、このような状況を打破すべく本を書こうと思い立ったのでした。『Webを支える技術』というタイトルから想像する技術は人によって異なると思いますが、本書で対象としている技術は副題にある「HTTP、URI、HTML、そしてREST」です。ちなみにHTMLは代表例で本書では他のハイパーメディアフォーマット(Atom、JSON)も扱っています。これらの仕様を解説しながら、この仕様はなぜこうなっているのか、どのように使えばいいのか、を本書では解説しています。

目次は以下のような感じです。大きくわけて5部構成で、第1部はWebの歴史とRESTについて、第2部はURIの仕様、第3部はHTTPの仕様、第4部はHTML、Atom、JSONの仕様、第5部はWeb サービスの設計になっています。

◇第1部 Web概論
□第1章 Webとは何か
■1.1 すべての基盤であるWeb
■1.2 さまざまなWebの用途
■1.3 Webを支える技術
■1.4 本書の構成
□第2章 Webの歴史
■2.1 Web以前のインターネット
■2.2 Web以前のハイパーメディア
■2.3 Web以前の分散システム
■2.4 Webの誕生
■2.5 Webの標準化
■2.6 Web APIをめぐる議論
■2.7 すべてがWebへ
□第3章 REST ── Webのアーキテクチャスタイル
■3.1 アーキテクチャスタイルの重要性
■3.2 アーキテクチャスタイルとしてのREST
■3.3 リソース
■3.4 スタイルを組み合わせてRESTを構成する
■3.5 RESTの2つの側面
■3.6 RESTの意義

◇第2部 URI
□第4章 URIの仕様
■4.1 URIの重要性
■4.2 URIの構文
■4.3 絶対URIと相対URI
■4.4 URIと文字
■4.5 URIの長さ制限
■4.6 さまざまなスキーム
■4.7 URIの実装で気をつけること
□第5章 URIの設計
■5.1 クールなURIは変わらない
■5.2 URIを変わりにくくするためには
■5.3 URIのユーザビリティ
■5.4 URIを変更したいとき
■5.5 URI設計のテクニック
■5.6 URIの不透明性
■5.7 URIを強く意識する

◇第3部 HTTP
□第6章 HTTPの基本
■6.1 HTTPの重要性
■6.2 TCP/IPとは何か
■6.3 HTTPのバージョン
■6.4 クライアントとサーバ
■6.5 リクエストとレスポンス
■6.6 HTTPメッセージ
■6.7 HTTPのステートレス性
■6.8 シンプルなプロトコルであることの強み
□第7章 HTTPメソッド
■7.1 8つしかないメソッド
■7.2 HTTPメソッドとCRUD
■7.3 GET ── リソースの取得
■7.4 POST ── リソースの作成、追加
■7.5 PUT ── リソースの更新、作成
■7.6 DELETE ── リソースの削除
■7.7 HEAD ── リソースのヘッダの取得
■7.8 OPTIONS ── リソースがサポートしているメソッドの取得
■7.9 POSTでPUT/DELETEを代用する方法
■7.10 条件付きリクエスト
■7.11 べき等性と安全性
■7.12 メソッドの誤用
■7.13 Webの成功理由はHTTPメソッドにあり
□第8章 ステータスコード
■8.1 ステータスコードの重要性
■8.2 ステータスラインのおさらい
■8.3 ステータスコードの分類と意味
■8.4 よく使われるステータスコード
■8.5 ステータスコードとエラー処理
■8.6 ステータスコードの誤用
■8.7 ステータスコードを意識して設計する
□第9章 HTTPヘッダ
■9.1 HTTPヘッダの重要性
■9.2 HTTPヘッダの生い立ち
■9.3 日時
■9.4 MIMEメディアタイプ
■9.5 言語コード
■9.6 コンテントネゴシエーション
■9.7 Content-Lengthとチャンク転送
■9.8 認証
■9.9 キャッシュ
■9.10 持続的接続
■9.11 そのほかのHTTPヘッダ
■9.12 HTTPヘッダを活用するために

◇第4部 ハイパーメディアフォーマット
□第10章 HTML
■10.1 HTMLとは何か
■10.2 メディアタイプ
■10.3 拡張子
■10.4 XMLの基礎知識
■10.5 HTMLの構成要素
■10.6 リンク
■10.7 リンク関係 ── リンクの意味を指定する
■10.8 ハイパーメディアフォーマットとしてのHTML
□第11章 microformats
■11.1 シンプルなセマンティックWeb
■11.2 セマンティクス(意味論)とは
■11.3 RDFとmicroformats
■11.4 microformatsの標準化
■11.5 microformatsの分類
■11.6 microformatsとRDFa
■11.7 microformatsの可能性
■11.8 リソースの表現としてのmicroformats
□第12章 Atom
■12.1 Atomとは何か
■12.2 Atomのリソースモデル
■12.3 エントリ ── Atomの最小単位
■12.4 フィード ── エントリの集合
■12.5 Atomの拡張
■12.6 Atomを活用する
□第13章 Atom Publishing Protocol
■13.1 Atom Publishing Protocolとは何か
■13.2 AtomPubのリソースモデル
■13.3 ブログシステムを例に
■13.4 メンバリソースの操作
■13.5 サービス文書
■13.6 AtomPubに向いているサービス
□第14章 JSON
■14.1 JSONとは何か
■14.2 メディアタイプ
■14.3 拡張子
■14.4 データ型
■14.5 JSONPによるクロスドメイン通信
■14.6 ハイパーメディアフォーマットとしてのJSON

◇第5部 Webサービスの設計
□第15章 読み取り専用のWebサービスの設計
■15.1 リソース設計とは何か
■15.2 リソース指向アーキテクチャのアプローチ
■15.3 郵便番号検索サービスの設計
■15.4 Webサービスで提供するデータを特定する
■15.5 データをリソースに分ける
■15.6 リソースにURIで名前を付ける
■15.7 クライアントに提供するリソースの表現を設計する
■15.8 リンクとフォームを利用してリソース同士を結び付ける
■15.9 イベントの標準的なコースを検討する
■15.10 エラーについて検討する
■15.11 リソース設計のスキル
□第16章 書き込み可能なWebサービスの設計
■16.1 書き込み可能なWebサービスの難しさ
■16.2 書き込み機能な郵便番号サービスの設計
■16.3 リソースの作成
■16.4 リソースの更新
■16.5 リソースの削除
■16.6 バッチ処理
■16.7 トランザクション
■16.8 排他制御
■16.9 設計のバランス
□第17章 リソースの設計
■17.1 リソース指向アーキテクチャのアプローチの落とし穴
■17.2 関係モデルからの導出
■17.3 オブジェクト指向モデルからの導出
■17.4 情報アーキテクチャからの導出
■17.5 リソース設計で最も重要なこと

◇付録
□付録A ステータスコード一覧
□付録B HTTPヘッダ一覧
□付録C 解説付き参考文献

2年の連載(全12回)のベースがあるから比較的楽に書けるよなーと最初は楽観的に思っていたのですが、これが大間違いでしたw。はっきりいって原型をとどめているところはほんの少しだけになっています。連載時の原稿は本書の100ページ分くらいだったので、最初はページ数が足りるかどうか心配だったのですが、書いてみたらなんと400ページの本になってしまいました。前付けと後付けを除くと350ページ強なので、2/3を書きおろしたことになります。また、連載時の原稿もかなり修正したり切り貼りしたり、校正したりしてあるのでバグも直っているし文章も読みやすくなっているはずです。

業務連絡:すでにAmazonなどには本書の情報が載っていて、ブックマークもされているのですが2つ変更点をお知らせします。

1つめは発売日についてです。Amazon上は3/18発売になっているかと思いますが、これが諸般の大人の事情で4/8になりました。すでにAmazon等で予約してくださったかたには3週間ほどの延期になってしまいます。申し訳ありません。

2つめの変更点は価格です。発売日延期のお詫びというわけではないですが、10円値下げして2570円+税になりました。なので税込2700円以内で買えるようになりました。それでもやっぱり技術書は高いのですが、技評さんに頑張ってもらいました。

追記(2010-03-07) Amazon上の発売日と価格、そしてタイトルの誤記が直りました。

最後にイベントのお知らせです。発売日の4/8(木)に合わせて、ジュンク堂書店池袋店にてトークセッションをやります。さすがに僕一人で話すのは無理なので、レビュアをお願いしたt-wadaさんにお願いしました。なのでこのトークセッションは自動的に第4回卓人の部屋になる予定ですw。

なお、ジュンク堂さんでは本書の発売に合わせてフェアもやってくださるそうなので、トークセッションにいらしていただくといろいろ面白い本が一緒に買えると思います。まだ何を話すのかとか全然決まっていないのですが、少しでも面白い話をできるように和田さんと打ち合わせるようにします。よろしくお願いします。

あ、あともう一つ忘れていました。本書の公式ハッシュタグは「webtechbook」になりました。高橋さんの命名です。すでにtwitterでは少しだけ使い始めています。このエントリのタグもwebtechbookにしました。ご愛用ください。それからtogetterにまとめページがあります。このハッシュタグを使ってもらえるとまとめやすくなると思います。

最後に、gihyo.jpでそのうち公開されるはずですが、本書のはじめにから少しだけ引用しておきます。

システムとしてのWebの構造や設計思想、いわゆるアーキテクチャは初期からほとんど変わっていません。最初のWebブラウザと現在のWebブラウザでは実現している機能に雲泥の差がありますが、使っているプロトコルは依然としてHTTPですし、表示しているのは昔も今もHTMLです。Webが誕生してから20年、常に新しい技術が生まれてきました。しかしその基本となるアーキテクチャは同じです。これはアーキテクチャの完成度がとても高いことを示しています。

(中略)

しかし一方で、簡単に接続できなかったり、データを活用するのに特殊なノウハウが必要だったりするWebサービスも存在します。簡単に接続できるWebサービスと、接続するのが難しいWebサービスとの違いはどこにあるのでしょうか。

その答えは「Webらしい設計」にある、と筆者は考えています。サービスをWebらしく作ると、ほかのシステムと簡単に連携でき、将来の拡張も楽になるのです。良い設計のWebサービスは、Web全体のアーキテクチャと調和しています。Webらしい良い設計をするためには、Webのアーキテクチャを理解して意識することが大切です。

 本書は、WebサービスをいかにWebらしく設計するかをテーマとしています。クライアントとサーバはどのように役割分担するのか、望ましいURIとはどのようなものか、HTTPメソッドはどのように使い分けるのか。Webサービスにおけるこれらの設計課題について、現時点でのベストプラクティスを紹介します。このテーマを実現するために、本書は次の2つの目的を持って執筆しました。

(中略)

本書の対象読者は、規模の大小にかかわらずWeb技術を使ったシステムを開発した経験のある人です。本書にはプログラミング言語のコードはほとんど登場しません。なぜなら、アーキテクチャは実装よりも1段階抽象度が高い概念だからです。その代わりに登場するのが、具体的なHTTPのやりとりです。HTTPのライブラリは、ほとんどすべてのプログラミング言語で用意されています。読者のみなさんが得意な言語でどのように実装するかを想像しながら読んでいただけると、よりわかりやすくなると思います。

ラベル:

1 Comments:

At 2010年3月3日 18:01:00 JST, Blogger Takeo Kunishima said...

おー、おもしろそうだ! 買います!

 

コメントを投稿

<< Home