うぃろぅ.log

140字で綴りきれない日々の徒然備忘録

【FjordBootCamp】 「Webを支える技術」を読む

うぃろぅです。

ありがたいことにプロジェクトの隙間時間に技術書を読むことが許可されているため、フィヨルドブートキャンプの課題の一環である本を読んでいきます。

今回の本

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

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

Webの基礎を学ぶ本。詳細に内容を書いてしまことは問題があるため、理解したことをまとめていく。

第1部 Web概論

  • Webの歴史について
    歴史の授業が苦手だったことを思い出すなど。
  • URIってなんなのさ
    リソースを一意に特定する識別子のこと。
  • RESTってなんなのさ
    • クライアント / サーバ
    • ステートレスサーバ
    • キャッシュ
    • 統一インターフェース
    • 階層化システム
    • コードオンデマンド
      以上の6つを組み合わせたアーキテクチャスタイルのこと。
      それぞれについての詳細は書籍参照。
      全てを兼ね備えてなければならない、というわけではなく、これらはRESTの基本となる考え方というだけ。
      そのため、業務内容によっては細かな変更をして設計する、ということも大いにあり。

ここから、「RESTful」な考え方についての説明や設計について語られていくという引き。

歴史が説明されている箇所では細かな用語の説明がなく、順次言葉の解説がされていくスタイル。
そのため、読み始めたときは全く意味が頭に入ってこず、非常につらかった。
この「わけわかんないけれどとりあえず読み進めていく」感じ、学生のときみたいだ…。

第2部 URI

  • URIの意義
    DBの主キーみたいなもの。そりゃ大事だわ。
  • URIの例
    ユーザ情報も含められることは知らなかった。やらないだろうけれど。
  • クールなURIを設計するために
    変化しにくいURI設計のポイントが解説されている。例えばプログラム言語に依存するURIにはしない方がいい等。
    試しに自社のグループサイトを見てみたらURI.../cgi-bin/...とあって悲しい気分になったりなど。というか?_=(謎の文字列)とか?cmd=hogehogeみたいなURIが乱立していてこれは…これは…っ!!

URIはアドレス欄に表示されるものであり、寿命が長いものでもあるため、設計時に強く意識する必要がある。

設計の手法については第5部で解説する。

第3部 HTTP

  • TCP/IPとは何か
    情報試験でよく見る階層化プロトコル
    わかりやすい記事があったため貼っておく。
    www.itbook.info
  • HTTPの歴史
    本書の発売時点では公開されていなかったHTTP/2が今の時代にはある。
    qiita.com
    リクエスト / レスポンスを多重化できることが大きな違い。それとサーバ側から能動的にデータをプッシュする機能があること。
  • HTTPメッセージの内容
  • ステートレス / ステートフル
    サーバがクライアントのアプリケーション情報を保存するか否か。ステートレスの場合やり取りが冗長になるが、サーバにかかる負担が減る。しかし通信エラー時に多重リクエストが送られてしまう危険性もあるため一長一短。
  • HTTPメソッド
    たった8つしかない。あまり使わないものを省くと6つ。これなら覚えられそうじゃない??
    POSTの誤用の最たる例としてXML-RPCが挙げられているが、以前携わったプロジェクトの通信規格がXML-RPCだった。切ない気分になるなあ。
  • ステータスコードについて
    ステータスコードの1文字目を見ると概要がわかるようになっている。
  • HTTPヘッダについて
    キャッシュの扱いや認証など様々なことをヘッダでやりとりする。
    電子メール仕様から拝借したり文字コードの取り扱いがブラウザによって異なったりと魔境。都度都度調べる必要がありそう。

クライアントとサーバでデータをやり取りする際の約束事や歴史について。
多分この部は何度も読み返すことになりそうな予感。

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

  • HTML
    タグで文書の構造を表現する。出版時はHTML5が仕様策定中とのこと。時代は確実に進んでいっている。
    なので本文中の<object>タグは<video><audio>タグなどで置き換え可能。どんどん利用していこう。
    reference.hyper-text.org
    また、rel属性はHTML5において自由に拡張できなくなった。
    www.htmq.com
  • microformats
    HTMLでは表現できないリンクの細かい意味やイベント情報を表す。
    HTML5においても引き続き利用できるが、いくつか注意点はある。
    rev属性やprofileの削除など。
    http://html5doctor.com/microformats/html5doctor.com
    英語なのでざっくりとしか理解できない(私は英語が得意ではないため。勉強する意思はある)が、いくつかの注意点を意識しておけばHTML5でもmicroformatを利用できる、ということが書いてある。はず。

    So where does that leave us? Well, if you keep the above caveats in mind you can safely use microformats in HTML5.

  • Atom
    エディタの方ではない。ちなみにエディタはこちら。
    atom.io
    Atom Syndication Format、略してAtomWebサービスのWeb APIとして利用できる。 細かく指定できて便利そうなのだが、自分がまだ使っていないためいまひとつ理解しきれていない。
  • JSON
    こちらはよくみるフォーマット。簡単なデータ構造の管理ならDBよりコストがかからない。
    プログラミング言語におけるハッシュやディクショナリのような記法のため直感的に理解しやすい。
  • JSONP
    scriptタグを利用して異なるドメインと通信して情報を取得する仕組み。
    blog.ohgaki.net
    便利だからといって手放しで使えばいいというわけではない。
    簡単な公開情報のやりとりに使うなら良さそう。

第5部 Webサービスの設計

この本ではリソース設計について扱う。
恐らくこの部がこの本の肝。

  • 読み取り専用のWebサービス設計
    「リソース指向アーキテクチャ」の設計手法について。
    • アドレス可能性
      リソースの主キー。最重要。
    • 接続性
      リンクをたどれるかどうか。アドレス可能性の次に重要。
    • 統一インターフェース
      接続性の次に重要。どのメソッドを採用するかよく検討しよう。
    • ステートレス性
      そこまで重要ではない。現実的に考えてCookieによるセッション管理がほぼ必須なため。
  • 書き込み可能なWebサービス設計
    トランザクション処理(いくつかのデータの整合性を保つ処理)やPUTPOSTのどちらを使うか、同時に更新が走った場合の対処など、こちらも悩みの種が多い。
    トランザクション処理を実装する場合はトランザクション処理用のリソースを追加し、そのリソースを使ってやり取りをするのが定石。
  • リソース設計
    リソースはどのように抽出していくべきか、というお話。
    3つの対象が挙げられている。

WebサービスもWeb APIもWeb技術を使ったインターフェースのため、分けて考えないことが大前提である、ということが再三強調されていた。

付録

ステータスコード一覧やヘッダ一覧など。

ぱらぱらと眺めていくと面白い。ここも読み返すことがありそう。

まとめ

毎日触れている「Web」の基幹を支える技術の基礎がこれでもかと詰まっている。
数回読み返すことで定着するタイプの書籍のため、折を見て読み返していきたい。

ちなみに1周目は全て読み終えるまで1週間ほどかかった。
業務の合間にとはいえもう少しペースを上げられたのではないかと見直しつつ次はもう少し効率的に読めたらいいね。

ではまた。