Your SlideShare is downloading. ×
『RESTful Web サービス』読書会 第4回 9章 説明資料
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

『RESTful Web サービス』読書会 第4回 9章 説明資料

1,922

Published on

『RESTful Web サービス』読書会 第4回 …

『RESTful Web サービス』読書会 第4回
9章「サービスの基本要素」
説明資料
レイアウトが崩れているので handsout.jp にも掲載

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,922
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 『 RESTful ウェブサービス』 第 4 回読書会 第 9 章 サービスの基本要素 Siena. (2008/07/12 Sat)
  • 2. 9章の概要
    • ここまでの焦点
      • HTTP, URI, XML
    • 他に必要な追加技術 : 例えば
      • ドメイン固有の XML 語彙
      • 統一インタフェースを提供するための標準ルール
    • 9 章の目的
      • ウェブサービスを改善する複数の技術の紹介
    • 凡例
      • 平文 , 要点 , 肯定的観点 , 否定的観点 , 個人的な補足
      • program code
  • 3. 9章のおしながき
    • 9.1 表現フォーマット
      • XHTML, microformats, Atom, SVG, フォームエンコードされたキーと値の組 , JSON, RDF と RDFa, フレームワーク固有の直列化フォーマット , 特別な XHTML, 他の XML 標準と一時的語彙 , エンコーディングの問題
    • 9.2 パッケージ済みの制御フロー
      • 一般規則 , DBMS と連動する制御フロー , AtomPub, GData, POST Once Exactly
    • 9.3 ハイパーメディアテクノロジ
      • URI Template, HTML4 (XHTML), HTML5, WADL
  • 4. 9.1 表現フォーマット
  • 5. 9.1 表現フォーマット
    • 表現のフォーマットはどのようなものにすべきか
      • オレオレ XML 語彙を使わないですむように
      • どのような選択肢があるかの確認
    • ここでの想定
      • クライアントは ( サービス提供者が適切に決定した ) いかなる表現フォーマットも受入可能
      • クライアントの既知の要件を優先
        • 例 : Excel へ直接入力されるなら CSV データを提供する
      • 人間にしか理解できないドキュメント形式は除外
        • 例 : オーディオデータ
  • 6. 9.1.1 XHTML
    • メディアタイプ
      • application/xhtml+xml
      • 従来の HTML (text/html) とは異なる
        • IE (6 まで ?) が HTML として扱うのは text/html のみ
        • XHTML でも、必要なら text/html として提供する
    • HTML ファミリ
      • HTML は、従来のウェブの原動力
      • XHTML は、プログラマブルウェブの原動力となりえる
        • XHTML を妥当な XML として表現するための制約に従う
        • HTML とは、いくつかの構文上の違いがある
  • 7. 9.1.1 XHTML
    • XHTML と比較した HTML
      • XML パーサで確実な解析はできない ので勧めない
      • 優れた HTML パーサが存在するので選択肢の一つ
        • それでもパース失敗することがしばしば
        • 妥当な HTML になっていないのが原因
        • 「データ提供者は規則に厳密に従い、 データ利用者は緩やかに解釈する」 という原則に期待できないのが現状
      • いくつかの HTML パーサは 2 章で紹介した
        • 「 2.5 レスポンスの処理 – XML パーサ」のこと ?
        • XML パーサしか紹介されていないような
      • 多くのクライアントに処理させるには XHTML を勧める
  • 8. 9.1.1 XHTML
    • HTML ファミリの特徴
      • 一般的なデータの多くを表現できる
        • リスト , 表など
      • ハイパーメディア形式が限られている
      • 統一インタフェースが完全にサポートされない
        • HTML5 で解決される予定
      • 意味的な表現力が不十分
        • コードや出力のみで、詩などの形式を対象としていない
      • 要素内容を表すメタデータの記述力が弱い
        • rel, rev 属性に指定できるのは 15 種類の関係のみ
        • リストの種類を class 属性で指定しても機械可読でない
        • ユーザが独自の値を定義すると相互運用性が失われる
        • microformats も参照
  • 9. 9.1.2 XHTMLとマイクロフォーマット
    • メディアタイプ
      • application/xhtml+xml
    • microformats
      • URI: <http://microformats.org/>
      • XHTML に ドメイン固有の意味を付与 する簡易標準
      • 既存の語彙を使用
      • class, rel, rev 属性の値を独自に拡張定義
    • 例 : hCard による自宅電話番号
      • <span class=“tel” > <span class=“type” >home</span> <span class=“value” >+1.415.555.1212</span> </span>
  • 10. 9.1.2 XHTMLとマイクロフォーマット
    • hCalendar
      • カレンダーやイベント情報
      • IETF iCalendar フォーマットがベース
    • hCard
      • 連絡先
      • RFC 2426 (vCard) がベース
    • rel-license (rel 属性値 )
      • 文書のライセンス条項へのリンクであることの明示
      • <a href= “http://creativecommons.org/ licenses/by-nd” rel=“license” > この文書のライセンス </a>
  • 11. 9.1.2 XHTMLとマイクロフォーマット
    • rel-nofollow (rel 属性値 )
      • リンクするが、必ずしも承認するとは限らないことの明示
    • rel-tag (rel 属性値 )
      • 外部の分類システムにしたがったラベル付けであることの明示
    • VoteLinks (rev 属性値 )
      • rel-nofollow の概念の拡張
      • <a rev=“vote-for” href=“http://example.com”> 最高のページ </a>, <a rev=“vote-against” href=“http://example.com”> 盗作 </a>
  • 12. 9.1.2 XHTMLとマイクロフォーマット
    • XFN (XHTML Friend Network) (rel 属性値 )
      • 対人関係
      • <a rel=“spouse” href=“Bob”>Bob</a>
    • XMDP (XHTML MetaData Profiles)
      • 定義リストを用いた XHTML の独自属性値の定義
      • rel-tag などの定義に利用可能
    • XOXO (Extensible Open XHTML Outlines)
      • リストが文書のアウトラインであることを明示
  • 13. 9.1.2 XHTMLとマイクロフォーマット
    • 執筆時点で既知の microformats
      • microformats Wiki <http://microformats.org/wiki/>
      • 公式なドラフトが約 10 個
      • 議論中のものが 50 個以上
        • geo : 緯度・経度
        • hAtom : Atom を XHTML で表記
        • hResume : 経歴
        • hReview : 批評
        • xFolk : ブックマーク (7 章の例に使用可能 )
  • 14. 9.1.3 Atom
    • メディアタイプ
      • application/atom+xml
    • Atom
      • タイムスタンプつきの エントリ のリストの説明
        • 作者 , 寄稿者 , 言語 , 著作権情報 , タイトル , カテゴリなど
      • ブログの更新情報の フィード などに利用
      • 乱立した RSS 群の統合と、一般化が目的
      • 多くのクライアントで利用可能
    • 例 9-2
      • URI で与えられたリソースのメタデータが記述されている
      • リソースの詳細は GET して取得
  • 15. 9.1.3 Atom
    • Atom の利用例
      • 一般にリソースのディレクトリとみなせる
        • フォトギャラリーやミュージックアルバム、検索結果などに
      • link などを省略可能
        • ステータスレポートや受信メールなどのコンテナとして
    • Atom の拡張利用
      • 名前空間を用いて独自の語彙で追加データを記述
      • 汎用のコンテナとして利用可能
  • 16. 9.1.3 Atom
    • OpenSearch
      • Atom において、よく利用される語彙
      • 検索結果一覧の表現
      • 独自の名前空間で追加される要素
        • totalResult : 結果の合計数
        • itemsPerPage : 検索結果のページ当たりの項目数
        • startindex : このフィードに含まれる部分結果の開始位置
  • 17. 9.1.4 SVG
    • メディアタイプ
      • image/svg+xml
    • SVG (Scalable Vector Graphics)
      • ベクトルグラフィックフォーマット
      • XML で記述
  • 18. 9.1.5 フォームエンコードされたキーと値
    • メディアタイプ
      • application/x-ww-form-urlencoded
    • URI エンコードされたフォーム入力値
      • 6 章を参照
      • Ajax アプリケーションで簡単に生成可能
      • CSV や RFC822 スタイルのキー値ペアを置き換え可能
      • クライアントが汎用のデコードライブラリを持つ
        • 訳注 : 日本語の扱いに注意 , charset パラメータを使用
      • 参考 : HTML4 仕様書では & 区切りでなく ; 区切りを推奨
  • 19. 9.1.6 JSON
    • メディアタイプ
      • application/json
    • JSON (JacaScript Object Notation)
      • 半構造データの記述に向いた軽量フォーマット
      • 2.5 節を参照
      • RFC4627 で標準化
  • 20. 9.1.7 RDF と RDFa
    • RDF (Resource Description Framework)
      • リソースに関する知識を表現
      • Semantic Web の基礎技術
        • OWL や SPARQL など多段のスタック
      • 機械可読な意味を表現
      • URI として ISBN や URN などの抽象 URI を多様
      • 三つ組み (triple) < 主語 , 述語 , 目的語 >
        • 複数の三つ組みによりグラフを構成
    • 例 9-4: “RESTful Web Services” の書籍
      • 主語 : urn:isbn:...
      • 述語 : dc:title ( メタデータ標準 Dublin Core)
      • 目的語 : RESTful Web Services
    主語 目的語 述語
  • 21. 9.1.7 RDF と RDFa
    • RDFa
      • microformats のように埋め込める
      • XHTML2 を想定しており、 現状では妥当ではなくなる
    • eRDF
      • RDF アサーションを表現する第 3 の方法
      • 妥当な XHTML になる
    • microformats との関係
      • どちらもメタデータを記述する
      • microformats: 軽量で簡易 , 意味を付加するのに向く
      • RDF: 汎用的で多機能 , Semantic Web スタックの利用や、既存 RDF 処理系との相互運用性が必要な場合など
  • 22. 9.1.8 FW固有の直接化フォーマット
    • メディアタイプ
      • application/xml
    • フレームワーク固有の XML 語彙
      • Ruby: ActiveRecord
      • Python: Django
      • 例 7-4 を参照
    • 7 章や 12 章で言及しているように 推奨しない
      • 短期での開発では妥協の余地あり
      • フレームワーク依存
      • シリアライズされたデータ構造に過ぎない
      • 文書ではなくハイパーリンクやフォームを含まない
  • 23. 9.1.9 特別な XHTML
    • メディアタイプ
      • application/xhtml+xml
    • 特殊な表現が必要か ?
      • 既存技術で表現できない正当な理由があるか再確認する
        • HTML ファミリ , Atom, RDF, JSON
      • 問題を正しく捉えていない可能性はないか
    • microformats 仕様の作成
      • 可能なら公式に提案して相互運用性を確保 ( 仕様先行 )
      • 作成文書に段階的に意味を付加し、その場限りで利用
      • microformats Wiki のデザインパターンと命名規則を参照
  • 24. 9.1.9 特別な XHTML
    • 主要なデザインパターン
      • HTML 要素型があればそれを利用
        • キー値ペア : dl
        • リスト : ul, ol
        • 適するものがない : span, div
      • class 属性を指定してタグに追加の意味を付与
        • 特に span, div で重要
      • 関係の付与
        • rel 属性 : このリソースと他のリソースとの関係
        • rev 属性 : このページと他のページとの関係
        • 関係が対称な場合は rel を使用
      • class, rel, rev を説明する XMDP ファイルの作成を検討
  • 25. 9.1.10 その他のXML語彙
    • メディアタイプ
      • application/xml
    • 既存の XML 語彙の利用
      • XMathML, OpenDocument, Chemical Markup Language, ...
      • Dublin Core, FOAF, ... (RDF アサーションで利用可能 )
  • 26. 9.1.10 その他のXML語彙
    • 独自 XML 語彙の作成
      • 本書では最後の手段とみなす
      • 一般には様々な語彙が作成されている
        • 本書で言及したウェブサービスのほぼすべてでも
    • 技術文化の違い
      • microformats は新しく、非公式なものとみなされがち
      • 独自 XML 語彙の作成が正当な手段のようにみなされる
      • これは勘違い
        • スキーマが定義されなければ、 microformats による 属性の独自値の導入と同程度
        • スキーマ定義は語彙を ( 名前空間で ) 分類可能にするのみ
        • ( 独自語彙の導入という選択を ? ) 正当化するものではない
  • 27. 9.1.10 その他のXML語彙
    • 適切な技術選択をせよ
      • 不必要に独自定義を持ち込まない
        • 既存の XML 語彙
        • 既存の microformats
        • 検討中の他の非公式だが有力な候補の利用
      • 検討の結果、必要なら独自定義を行なう
        • 要素の導入が不要なら microformats の利用を検討
        • 要素の導入が必要なら XML 語彙を定義
          • この場合に microformats による拡張は不適切
  • 28. 9.1.11 エンコーディングの問題
    • 多言語への考慮
      • 文字エンコーディングを理解する
        • 符号化文字集合 (CCS : Coded Character Set)
        • 文字符号化方式 (CES : Character Encoding Scheme)
      • 言語圏ごとに様々な文字エンコーディングが存在
    • Unicode
      • 主な符号化方式 : UTF-8 (US-ASCII 上位互換 ), UTF-16
      • 多言語データを扱う最良の決断 : Unicode に統一
        • 指摘されている問題も把握すべき , 盲目的に過信しない
    • 文字コード検出
      • Python: Univeral Encoding Detector
      • Ruby: chardet gem
  • 29. 9.1.11 エンコーディングの問題
    • 文字コード変換時の考慮点
      • 全てのテキストを UTF-* に変換
      • エンコーディングが未指定もしくは未知の場合
        • 自動検出して変換
        • 理解不能なものとして拒否
    • クライアントとの通信
      • XML 宣言で encoding を指定
      • <?xml version=“1.0” encoding=“utf-8” ?>
  • 30. 9.1.11 エンコーディングの問題
    • XML と HTTP で競合する場合
      • XML 文書中に記述されたものより、 HTTP の Content-Type 応答ヘッダで指定されたものが優先 (RFC3023)
      • プログラマはこれを知らないまま、 XML 文書を作成してしまうことが多いので注意
      • HTML4 以降の仕様でも同様だが知られていない ?
    • メディアタイプと文字エンコーディング
      • 提供する XML 文書は text/xml ではなく application/xml
      • charset なしの text/xml の場合は、文書中の エンコーディング指定を無視し、 US-ASCII とみなすべき
      • application/xml で XML 宣言でエンコーディングを指定
  • 31. 9.1.11 エンコーディングの問題
    • JSON 文書の文字エンコーディング
      • プレーンテキスト
        • 構造化されていない
        • 文字エンコーディングを指定する方法がない
      • このため、 JSON は文字エンコーディングを指定不可能
      • RFC4627 では UTF-* であることが規定 されている
        • UTF-8, BOM 付き UTF-16 (, US-ASCII)
        • 最初の 4 バイトで判別可能
  • 32. 9.2 パッケージ済みの制御フロー
  • 33.
    • HTTP 標準応答コード
      • サーバから提案された制御フロー
    • 参考資料
      • HTTP 1.1 Headers Status Diagram <http://thoughtpad.net/alan-dean/http-headers-status.gif>
      • この図の方が 9.2.1, 9.2.2 より有用
    9.2 パッケージ済みの制御フロー
  • 34. 9.2.1 一般規則 , 9.2.2 制御フロー
    • 9.2.1 一般規則
      • ほぼすべてのサービスに適用可能な標準的な制御フロー
      • 401 : Unauthorized
      • 404 : Not Found
      • 405 : Method Not Found
    • 9.2.2 DB と連動する制御フロー
      • メソッド別の基本的な応答コード
      • GET
      • PUT
      • POST
      • DELETE
  • 35. 9.2.3 Atom Publishing Protocol
    • AtomPub
      • HTTP 統一インタフェース上の 高水準統一インタフェース
      • Atom 文書をエンドユーザに提供することが目的
      • 表 9-1: AtomPub リソースとメソッド
    • 構成要素
      • コレクション
      • メンバ
      • サービス文書
      • カテゴリ文書
    • AtomPub メンバとしてのバイナリ文書
      • URI で識別されるリソースとして同様
  • 36. 4.2.3 GData
    • GData
      • AtomPub の拡張
      • 新しい種類のリソースを追加
      • 承認メカニズムのような機能を追加
      • Google で働いてないと正確なインタフェースを サポートすることはない ?
    • 応用 (AtomPub + GData 拡張 )
      • Blogger
      • Google Calendar
      • Google Code Search
      • Google Spreadsheets
  • 37. 4.2.3 GData
    • コレクションの検索
      • 追加 : 検索結果のリスト
      • コレクションメンバの一部の表現の GET
    • データ拡張
      • Google Calendar の例
        • gd:when
        • gd:who
        • gd:recurrence
  • 38. 4.2.5 POST Once Exacly
    • POST の欠点
      • 信頼できる HTTP を台無しにすること
      • べき等ではないため、 何度も送信すると異なる効果
    • POE
      • POST を べき等にする ための手段
      • HTTP ヘッダに細工をする  ( 例 p.297)
  • 39. 9.3 ハイパーメディアテクノロジ
  • 40.
    • ハイパーメディアフォーマット
      • リンクとフォームを 構造的に サポートするフォーマット
    • フォーム
      • アプリケーションフォーム
        • アプリケーション状態の操作
        • リンクとあわせて本書の「接続性」を実装
        • Fielding のいう「アプリケーション状態の エンジンとしてのハイパーメディア」を実装
      • リソースフォーム
        • リソース状態の操作
        • GET, DELETE は表現は不要
        • POST, PUT には必要なので、それの要求の表現を伝える
    9.3 ハイパーメディアテクノロジ
  • 41. 9.3.1 URI Template
    • kunit さんにパス (w
  • 42. 9.3.2 HTML 4 (XHTML)
    • ハイパーリンク
      • a, link 要素
      • href 属性
      • rel, rev 属性 : microformats で属性値を拡張
    • フォーム
      • form 要素
    • 欠点
      • アプリケーションが 表現できる URI には制限 がある
      • フォームでは GET, POST しか使えない
      • クライアントの要求で 送信すべき HTTP ヘッダを説明不能
      • フォームで キー値ペアしか表現できない
      • フォームで 反復フィールドを定義できない
  • 43. 9.3.3 HTML 5
    • 仕様策定中
      • プログラマブルウェブを使用する上での問題の多くを解決
      • 2008 年末頃に勧告予定 ( 執筆時点 )
      • <http://www.w3.org/TR/2008/WD-html5-20080610/>
    • フォーム
      • GET, POST に加え、 PUT, DELETE をサポート ( 例 6-3)
      • URI Template 導入 の提案あり
      • 同じキー名の複数のパラメータを送ることをクライアントに伝える 「反復モデル」をサポート
      • フォーム入力値のシリアライズ方法の追加
        • キー値ペアのプレーンテキストとして
        • XML 語彙を用いて (application/x-www-form+xml)
  • 44. 9.3.4 WADL
    • まにあわなーい

×