『Webを支える技術』学習メモ

Web

Part1 Web概論

Ch01 what's Web

  • Webの作用
    • clientと疎結合なWeb site
    • UIとしてのWeb
    • APIとしてのWeb
    • HTTP, URI, HTML
  • 非線形なhyper media @Web
  • distributed system @Web
    • simple protocol

Ch02 Web history

  • Web以前のhyper media
    • hyper media: hyper textの拡張
  • 必要最小のリンク機能のみ持つWeb
    • RPC, CORBA, DCOM
  • Web以前のdistributed systemの問題
  • Webの起源
  • simpleな単方向リンク
  • client-server間のIF．simple protocolとしてのHTTP
  • IETF→W3Cでのstandardize
    • especially HTML, CSS
  • Webのstandardize
    • RESTの起源，意味
      • HTTPはresourceのstateの表現を転送している
      • REpresentational State Transfer
    • Hyper Media Format: HTML, RSS, Atom, microformat, JSON
  • Web API
    • SOAP @RPC/distributed object
      • WS-*
    • mashupのためのREST
  • REST, Ajax, CometによるWebの進化

Ch03 REST: Web architecture style

概要

  • architecture style: architecture pattern
    • e.g. MVC, Pipe&Filter, Event System
  • architecture style > micro architecture pattern(design pattern) @粒度
  • architecture styleをもとに，architectureを決定する

内容

  • REST: network systemのarchitecture style
    • Web: client/server style
  • REST: client/server + 制約
抽象度 Webでの例
architecture style REST
architecture browser, server, proxy, HTTP, URI, HTML
implement Apache, Firefix, IE

詳細

  • resource: Web上の名前を持ったあらゆる情報
  • resource name, identifier: URI
    • addressability
      • URIによってresourceが表す情報にアクセス
    • client-server間でやり取りするdata: resourceの表現
      • 1つのresourceは複数表現を持てる
        • e.g. html, pdf
  • RESTの構成
    • RESTは複数のarchitecture styleを組み合わせて構築した複合architecture
    • a.client-server
      • Web: httpでclient-serverが通信するというarchitecture style
      • merit: client-serverを分離できる
        • multi platform @client + serverの冗長化で可用性UP
    • b.stateless server
      • clientのapplicationのstateは管理しない
    • c.cache
      • resourceをclient側で再利用
    • d.統一IF
      • 統一IFにより，client-server間の独立性を高める
        • GET, POSTなど限定的なmethodのみを持つ
    • e.階層化system
      • 統一IFにより，load balancerやproxyを使用したsystemの階層化が容易になる
    • f.code ondemand
      • js, flash, java appletなど
      • merit: あとからclientを拡張
      • demerit: protocolの可視性down
    • a-fを組み合わせたarchitecture styleがREST
      • REST以外のarchitecture style: P2P
  • RESTの2つの側面
      1. RESTとHypermedia
      2. resourceをリンクで接続することで1つのapplicationを構成する
        • 接続性: RESTの基幹をなす
      1. RESTとdistributed system
      2. linkをたどってapplication stateを遷移することで性能劣化を抑える．
      3. 統一IFにより互換の問題が起こらない．

作用

  • RESTというdistributed network systemのための理論により，Webが機能する
  • RESTの制約に従っていること: RESTful

Part2 URI

Ch04 URIの仕様

目的

  • URI: Uniform Resource Identifier
    • resourceを統一的に識別するID

概要

  • URIのsimpleな構文
    • URI scheme: http → 一般にはprotocolを示す．「://」で区切る
    • host name: blog.example.jp → DNSで解決できるDNかIP address
    • path: /entries/1 → hostの中のresourceを一意に示す
  • URIの複雑な構文
    • URI scheme
    • user info: resourceにaccessする際のuser + pass 「user:pass」
    • host: user infoの後に「@」
    • port: hostにaccessするときのprotocolで用いるTCPのport number
      • 省略 → protocolのdefault. httpでは80
    • path
    • query parameter: 「path?query」となる． 「name=value」&「name=value」
      • dynamicにURI生成
    • URI fragment: URIのresource内部の部分を指定

詳細

  • 相対URI
    • 相対URIの解決のため，base URIを指定
      • base URI: resourceのURI or 明示指定
        • html: \<head>内に\<base>
        • xml: xml:base=""でどこでも〇
  • URIと文字
    • ASCII以外の文字のための%encode
      • → UTF-8の文字を構成するbyteそれぞれを「%xx（xxは16進数）」で表記
    • Web pageの文字encodingで%encodeを行う．基本はUTF-8
  • URIの長さ
    • 実装上は長さに制限あり
  • URI scheme
    • 既存のprotocol → 既存のscheme

まとめ

  • 相対URIの解決と%encodeが必要．
  • なるべく絶対URI & UTF-8

Ch05 URI design

目的

  • 変わらないURIがbest URI
    • called "cool URI"

概要

  • 変わりにくいURIの作成
    • 実装に依存した拡張子やpathを含めない
    • method nameやsession idを含めない
    • URIはresourceを表現する名詞にする

詳細

    1. Cool URI
    2. usability高まる
    1. URIの変更のためのredirect
    1. 拡張子でresourceの表現を特定
    2. 言語を指定する拡張子
      • → Content Negotiationのためのbrowserの設定不要
    1. matrix URIで複数の軸を;で区切る
    2. ;: 順不同
    3. ,: 順序アリ
    1. clientに対して不透明なURI → 疎結合

影響

  • URIは以下の点で重要
    • resourceの名前である
    • 寿命が長い
    • browser/address欄に表示
  • → Web ServiceやWeb APIのために最も重要なpart

Part3 HTTP

Ch06 HTTPの基本

目的

  • TCP/IPの基礎とHTTPの歴史を見る
  • HTTPは以下のRESTの重要な特徴を実現する，Webの基盤となるprotocol
    • 統一IF
    • stateless server
    • cache

概要

  • TCP/IPの観点
    • 階層型protocol → 層ごとに抽象化して実装
      • application layer
        • concreteなinternet application
          • mail, DNS, HTTP
          • socket(networkでのdataのやり取りを抽象化したAPI)と呼ばれるlibraryを利用して，HTTP serverやbrowserを実装
      • transport layer
        • dataの転送を保証．TCPに相当．
          • TCPで接続先とconnectionを構成し，1~65535のport numberでdataの転送先applicationを決定する
      • internet layer
        • IPでpacket単位でdataをやり取り．IPに相当．
        • 自分のnetwork IFでのdata送信の保証
      • network IF層
        • 物理的な部分

詳細

  • HTTP history
  • client-serverのarchitecture style
    • client ≒ user agent
  • request-response型のprotocol
    • @client, @server
  • HTTP message: request-response message
    • request messageの構成
      • request line
        • method, request URI, protocol version
      • header
      • body
    • response messageの構成
      • status line
      • header
      • body
  • stateless HTTP
    • application state = session state
      • statefulの欠点
        • client増 → scaleout difficult
    • stateless の利点
      • 自己記述的messageでscaleout easy
    • statelessの欠点
      • performance down
        • data量，冗長（認証など）
      • 通信エラー

作用

  • simple HTTPにより，Web ServiceとWeb APIが同じprotocolで表現

Ch07 HTTP methods

目的

  • 8 methodsのうち，主要な6つのmethodsの使い方を見る
  • and, HTTPの設計上の工夫を見る
  • method数が少ないからこそHTTPやWebは成功

概要

  • HTTP methodsの観点
    • CRUD
      • GET
      • POST: URIをserver側で自動決定するWeb Service
      • PUT: clientが決めたtitleがURIになる → PUTの方がserverと密
      • DELETE
    • HEAD
    • OPTIONS

詳細

  • methodの使用の観点
    • POSTでPUT/DELETEを代用
      • _method parameter
      • X-HTTP-method-override header
    • 条件付きrequest
    • 冪等性(idempotence)と安全性
      • idempotence: PUT, DELETE
      • idempotence and safe: GET, HEAD
      • どちらでもない: POST
    • methodのproper use
      • 他methodでできることにPOSTを使わない
      • PUTの冪等なuse
      • DELETEの冪等なuse

作用

  • 数少ないmethodによりprotocolをsimpleに保つ
  • RESTの統一IFの実現

Ch08 status code

  • 観点
    • status line
    • status codeの分類による意味
      • client-server間を疎結合に
      • 先頭の数字でclientが解釈
    • よく使われるcode
    • status codeとerror handling
      • {protocol, Accept header}に従ったformatのerror
    • status codeの設計

Ch09 HTTP header

目的

  • HTTPの構成要素
    • method
    • status code
    • header
      • meta dataをstandardize
      • 認証やcacheを実現
  • history
    • headerの成り立ち
      • mailと共通の部分
      • mailと異なり双方向

概要

  • 観点
    • GMTでのdate
    • MIME: Multipurpose Internet Mail Extensions
      • Content-Type
      • charset → textのときの文字化け
    • Content-Language: resource表現の自然言語
    • Content Negotiation: client がrequest
      • Accept
    • Content Length
    • chunk transfer @画像などを分割
    • 認証: realmの値: URI空間
      • Basic authentication: username & password
      • Digest authentication: with hash function
        • requestごとに401 responseがあるため普及しない
      • OpenID: single sign on
      • OAuth: 認可の以上
      • WSSE認証: serverは生password
    • cache
      • cache用headerでcontrol
      • 条件付きGET
    • 持続的接続 @HTTP1.1でdefault
      • pipeline化
      • closeで切断
    • その他のHTTP header

作用

  • various 技術標準の組み合わせでheaderを構成する．十分な調査によりHTTP headerを扱える．
  • authenticationやcacheなどのHTTPの重要な機能を実現

Part4 HyperMediaFormat

Ch10 HTML

  • HyperMediaFormatとしてのHTMLを見る
    • HTML: HyperText Markup Language
      • Markup Language: Tagで文書構造を表現
        • 構造化文書
      • SGML base(text/htmlのHTML) → XML base(application/xhtml+xml)
    • htmは古い拡張子
    • XML(meta language)の仕様
      • 書き方-link
    • ! HTMLでのlinkの設計: linkをたどってapplicationのstate 遷移

Ch11 microformats

目的

  • microformatsによりlinkの細かい意味やevent informationを表現

問題

  • semantics(意味論)
    • program semantics
      • program languageのもつ意味を確定させる理論
    • Web semantics「semantics Web」
      • resourceの持つ意味を確定させる理論
  • RDFの問題とmicroformatsでの解決

概要

作用

  • microformatsで解決できない部分
    • RDFa(RDF-in-attributes)での解決
    • 可能性
    • microformatsによりWeb pageをそのままWeb APIとして提供
      • Web page/APIの機能差少ない
      • 保守・開発コスト小さい

Ch12 Atom

目的

  • Atom Syndication Format
    • XML format
    • Web serviceのWeb APIとして使用

概要

  • resource model
    • member resource
      • entry resource @XML
      • media resource
    • collection resource
      • plural member resource
    • media type: app/atom+xml
    • atom extension

詳細

  • entryの構成
  • feedの構成
  • Atomの拡張
    • Feedの分割
    • archived feed
    • Open Search

作用

  • Atom: title, author, update timeなどの基本的なmeta dataを持ったresource表現のためのformat

Ch13 Atom Publishing Protocol

  • Atom Publishing Protocol
    • Atom: data formatの規定
    • Atom Publishing Protocol: Atomでのresource編集protocolの規定
      • Atomで表すresourceのCRUD操作のためのprotocol
  • Atom Publishing Protocolのresource model
    • 1つのresourceがmulti 表現
  • member resourceの操作
  • service document
  • Atom Publishing Protocolに向いている/いないWeb API

Ch14 JSON

  • JSON: hashや配列などのdata構造の記述
    • Notation
    • JSONとは
    • data type
    • Object: key-value
    • JSONP
      • cross domain communicationの制限
        • script要素での解決
        • Callback functionによるJSONP
    • Ajaxでは必須．

Part5 Web Serviceの設計

Ch15 Read Only Web Serviceの設計

目的

  • resource designの観点
    • client-server間IF: Web Service/APIの外部設計
      • resourceの分割
      • URIでの命名， 相互リンク
      • 設計の対象
    • Web Service/APIを区別しない

概要

  • resource指向のarchitectureのapproachの観点
    • ! 設計step
      • service dataの特定
      • dataをresourceに分ける
      • 各resourceに対して
        • resourceをURIで命名
        • client向けのresource表現の設計
          • linkとformでresource間を結びつけ
        • eventの標準的なコースの検討
        • errorの検討
  • RESTfulなWeb Serviceの性質
    • addressability
    • stateless
      • 接続性
      • 統一IF

詳細

  • 各手順の観点
    • dataのresourceへの分割
      • dataそのもの， 構造data含む
      • 機能の結果
      • top level resource
    • resourceへのURIでの命名
      • parameterの{~}記法
      • 階層構造のための「/」
    • clientへのresource表現
    • linkとformでresource間をつなげる
      • resource間のリンク関係
    • event error

作用

  • resource design skillの習得でよい設計

Ch16 writable Web Service

目的

  • ROのServiceより観点多い

概要

  • 観点
    • resource create/update/delete
    • batch処理
    • transaction
    • 排他

詳細

  • create
    • factory resource
    • PUT作成
      • 〇 作成と更新の区別不要
      • × clientにURI構造流出
  • update with PUT
    • bulk update
    • partial update → 通信料cut
    • update error
  • delete
    • 子resource
  • batch: POSTでURIを非指定
    • response
  • transaction
    • transaction resource
    • (or batchのtransaction化)
    • 上位resourceへの操作
  • 排他
    • pessimistic lock
      • LOCK/UNLOCK @WebDAV
      • 独自Lock resource
    • optimistic lock
      • conflictを解消
        • Condition PUT/DELETE

作用

  • 以下の観点でバランス
    • なるべくsimple
    • 別resourceで解決
    • 必要ならPOST

Ch17 resource design

目的

  • dataの特定とdataのresource分割のための方法を見る

内容

  • 関係モデルからの導出
    • data model with math的基盤
    • 中心tableの1行を1 resource
    • 自己記述のため非正規 → network負荷減
      • resourceに必要な項目をすべて入れる
    • 階層 difficult
    • linkのためのER図
  • Object Oriented modelからの導出
    • 主要entityからresource
    • 階層関係 → URI構造
    • link by object reference
    • top levelは別に作る
  • information architectureからの導出
    • information分類の観点: information architecture
    • resource oriented architectureと相互補完
      • information architectureがinformationを分類し，resource oriented architectureにつながる

作用

  • 既存の3つの手法を，serviceとAPIを分けずに用いることで，resourceを導出できる