• このエントリーをはてなブックマークに追加
P1380564 on Flickr

はじめに

先日amazonさんより届いた「Webを支える技術 -HTTP、URI、HTML、そしてREST」をひととおり読んでみました.2010年,初めて読み終えた本です,たぶん><

ひととおり読んでみて

恥ずかしながら,これまでHTTPに関して勉強という勉強をせず,知っている部分だけを感覚的にやりすごしてきたので,その中身を知るよい機会でした.Webサーバやブラウザがどのようにデータをやりとりしているか,のイメージが少しながら鮮明になったと思います.

また,「リソース」の定義や操作,それを指し示すURIの設計など,こちらも普段(個人的に)感覚的に行ってしまいがちなプロセスを,Web,特にHTTP,の特性(?)を意識して設計するように考え直させられました.

あと,いわゆる「Web」を教えるようなところでは,まずはこういった内容から初めてもいいんでないかな,とも思いました.三十路近くでAjaxを少し触っただけで「Webっていんじゃね?」とか思って何かそれっぽいことを始める人よりは,普段から(生まれてから?)インターネットに十分浸かっている若い人の方が吸収が早いのは明白でしょう.「Web」を扱う上では(それなりの革命が起きなければしばらくは)普遍的なことでしょうし.

Post-it

とりあえず「Post-it」したところをざっと羅列してみます.

URIはリソースを表現する名詞にする

あるリソースを取得するのか更新するのかは、URIで指定するのではなく、URIに適用するメソッドで決定します。
p.56

積極的に練習していきます.

マトリクスURI

    http://example.jp/map/lat=35.705471;lng=139.751898

p.62

    http://example.jp/map/35.705471,139.751898

p.63

多次元データをURIに含める例.

HTTPのステートレス性

p.80からのハンバーガーショップでのやりとりの例をたどって,次の一文でイメージがクリアになった感じです.

もちろんすべてのやりとりはステートレスですので、直接そのリソースを取得してもかまいません。ブラウザのアドレス欄にURIを入力すれば、郵便番号リソースや検索結果リソースを直接取得できます。

p.266

といっても,まだ完全につかめたわけではありませんが.

リソースヘッダの取得

HEADへのレスポンスにはボディが含まれません。この性質を利用すると、ネットワークの帯域を節約しながらリソースの大きさを調べたり、リソースの更新日時を取得したりできます。

p.97

XMLHttpRequestオブジェクト

Ajaxで用いるXMLHttpRequestというモジュールを利用すると、任意のメソッドを発行できるからです。
p.98

GETとPOSTしか使ったことがなかったので,考えたこともありませんでした><

ステータスコードの誤用

WebサービスでもWeb APIでも、HTTPのステータスコードを正しく使うことは最低限のマナーです。しかし、一部のWebサービスやWeb APIでは、エラーを200 OKで返すことがあります。
p.123

やっぱり意識しないとダメですね><

304 Not Modified

このレスポンスにはボディが含まれませんので、その分ネットワーク帯域を節約できます。
p.147

ハイパーメディアフォーマットとしてのHTML

HTMLでリンクを設計する際は、「リンクをたどることでアプリケーションの状態が遷移する」ことを強く意識しましょう。
p.173

elemental microformats (p.180)

rel-lisenceとかrel-nofollowとか.

そういえば,XFNとか,前にWordPressの管理ページで見かけた気がします.これもmicroformatsのひとつだったのですね.

compound microformats (p.181)

hCalendarとかhCardとかhAtomとか.

リソース設計

Webサービスで提供するものも、Web APIで提供するものも、結局はWeb上にあるリソースなのです。
p.243

リソース指向アーキテクチャ

  1. Webサービスで提供するデータを特定する
  2. データをリソースに分ける

そして、各リソースに対して次の作業を行います。

  1. リソースにURIで名前を付ける
  2. クライアントに提供するリソースの表現を設計する
  3. リンクとフォームを利用してリソース同士を結び付ける
  4. (ry

p.243

URI Templates

一部がパラメータとして変動するURIを記述する場合、「{」と「}」でパラメータ部分を囲むURI Templatesという表記が一般的です。
p.249

ファクトリリソースによる作成

ファクトリリソースとは、リソースを作成するための特別なリソースです。

p.269

バルクアップデート

このようにリソース全体を送信する更新方法を「バルクアップデート」(Bulk Update)と呼びます。

p.273

トランザクションリソース

トランザクションをRESTfulに実現する際の肝は、トランザクションリソースです。トランザクションリソースは、その名のとおりトランザクション情報を表現するリソースです。

p.279

412 Precondition Failed

条件付きPUTや条件付きDELETEを発行した際にリソースが変更されていた場合は、412 Precondition Failedが返ります。

p.293

設計のバランス

なるべくシンプルに保つ
設計が複雑になってきたら、機能が無駄に増えてきたら、1段階メタな視点で全体を考え直すこと。不要な機能や、やり方を変えることで削除できる機能があるかもしれない。(ry
困ったらリソースに戻って考える
HTTPメソッドでは実現できない機能があると感じたら、それが独立した別リソースで代替できないかを考える。検索機能を実現するSEARCHメソッドを追加するのではなく、「検索結果リソース」をGETする、と考えることが重要である
(ry

p.295

リソースが持つデータの特定

関係モデルではデータの重複を省くために通常は正規化を行いますが、リソースの設計では、一つ一つのリソースを、それ自身ですべてを表現できるように自己記述的にするために、あえて正規化を崩します。
p.299

参考

同書籍のサポートページに,正誤などがまとめられているので,あわせて参照するとよいでしょう.

おわりに

以上,「Webを支える技術 -HTTP、URI、HTML、そしてREST」を読んでみて、現在の自分に残った部分(Post-itで残しておいた部分?)を書き出してみました.

同書籍には「規模の大小にかかわらずWeb技術を使った開発経験のある人を対象読者」とありますが,これからWeb技術について学ぶ方とかまさに今学んでいる方とかも、読んでおいて損は皆無かと思います.

個人的には,今後のお仕事なりお遊びサービスなりにどんどん役立てていきたいところです.

amazonさん