『 RESTful ウェブサービス』

第 4 回読書会

第 9 章 サービスの基本要素

Siena.(2008/07/12 Sat)

9 章の概要• ここまでの焦点

– HTTP, URI, XML• 他に必要な追加技術 : 例えば

– ドメイン固有の XML 語彙

– 統一インタフェースを提供するための標準ルール

• 9 章の目的– ウェブサービスを改善する複数の技術の紹介

• 凡例

– 平文 , 要点 , 肯定的観点 , 否定的観点 , 個人的な補足– program code

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

9.1 表現フォーマット

9.1 表現フォーマット• 表現のフォーマットはどのようなものにすべきか

– オレオレ XML 語彙を使わないですむように

– どのような選択肢があるかの確認

• ここでの想定

– クライアントは ( サービス提供者が適切に決定した ) いかなる表現フォーマットも受入可能

– クライアントの既知の要件を優先• 例 : Excel へ直接入力されるなら CSV データを提供する

– 人間にしか理解できないドキュメント形式は除外

• 例 : オーディオデータ

9.1.1 XHTML• メディアタイプ

– application/xhtml+xml– 従来の HTML (text/html) とは異なる

• IE (6 まで ?) が HTML として扱うのは text/html のみ

• XHTML でも、必要なら text/html として提供する

• HTML ファミリ

– HTML は、従来のウェブの原動力

– XHTML は、プログラマブルウェブの原動力となりえる• XHTML を妥当な XML として表現するための制約に従う

• HTML とは、いくつかの構文上の違いがある

9.1.1 XHTML• XHTML と比較した HTML

– XML パーサで確実な解析はできないので勧めない

– 優れた HTML パーサが存在するので選択肢の一つ• それでもパース失敗することがしばしば

• 妥当な HTML になっていないのが原因

• 「データ提供者は規則に厳密に従い、 データ利用者は緩やかに解釈する」という原則に期待できないのが現状

– いくつかの HTML パーサは 2 章で紹介した

• 「 2.5 レスポンスの処理 – XML パーサ」のこと ?• XML パーサしか紹介されていないような

– 多くのクライアントに処理させるには XHTML を勧める

9.1.1 XHTML• HTML ファミリの特徴

– 一般的なデータの多くを表現できる

• リスト , 表など

– ハイパーメディア形式が限られている– 統一インタフェースが完全にサポートされない

• HTML5 で解決される予定

– 意味的な表現力が不十分• コードや出力のみで、詩などの形式を対象としていない

– 要素内容を表すメタデータの記述力が弱い

• rel, rev 属性に指定できるのは 15 種類の関係のみ

• リストの種類を class 属性で指定しても機械可読でない

• ユーザが独自の値を定義すると相互運用性が失われる

• microformats も参照

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>

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>

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>

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)– リストが文書のアウトラインであることを明示

9.1.2 XHTML とマイクロフォーマット

• 執筆時点で既知の microformats – microformats Wiki <http://microformats.org/wiki/>– 公式なドラフトが約 10 個

– 議論中のものが 50 個以上

• geo : 緯度・経度• hAtom : Atom を XHTML で表記

• hResume : 経歴• hReview : 批評• xFolk : ブックマーク (7 章の例に使用可能 )

9.1.3 Atom• メディアタイプ

– application/atom+xml

• Atom– タイムスタンプつきのエントリのリストの説明

• 作者 , 寄稿者 , 言語 , 著作権情報 , タイトル , カテゴリなど

– ブログの更新情報のフィードなどに利用

– 乱立した RSS 群の統合と、一般化が目的

– 多くのクライアントで利用可能

• 例 9-2– URI で与えられたリソースのメタデータが記述されている

– リソースの詳細は GET して取得

9.1.3 Atom• Atom の利用例

– 一般にリソースのディレクトリとみなせる• フォトギャラリーやミュージックアルバム、検索結果などに

– link などを省略可能• ステータスレポートや受信メールなどのコンテナとして

• Atom の拡張利用– 名前空間を用いて独自の語彙で追加データを記述– 汎用のコンテナとして利用可能

9.1.3 Atom• OpenSearch

– Atom において、よく利用される語彙

– 検索結果一覧の表現– 独自の名前空間で追加される要素

• totalResult : 結果の合計数

• itemsPerPage : 検索結果のページ当たりの項目数

• startindex : このフィードに含まれる部分結果の開始位置

9.1.4 SVG• メディアタイプ

– image/svg+xml

• SVG (Scalable Vector Graphics)– ベクトルグラフィックフォーマット

– XML で記述

9.1.5 フォームエンコードされたキーと値

• メディアタイプ

– application/x-ww-form-urlencoded

• URI エンコードされたフォーム入力値

– 6 章を参照

– Ajax アプリケーションで簡単に生成可能

– CSV や RFC822 スタイルのキー値ペアを置き換え可能

– クライアントが汎用のデコードライブラリを持つ• 訳注 : 日本語の扱いに注意 , charset パラメータを使用

– 参考 : HTML4 仕様書では & 区切りでなく ; 区切りを推奨

9.1.6 JSON• メディアタイプ

– application/json

• JSON (JacaScript Object Notation)– 半構造データの記述に向いた軽量フォーマット

– 2.5 節を参照

– RFC4627 で標準化

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

主語

目的語

述語

9.1.7 RDF と RDFa• RDFa

– microformats のように埋め込める

– XHTML2 を想定しており、現状では妥当ではなくなる

• eRDF– RDF アサーションを表現する第 3 の方法

– 妥当な XHTML になる

• microformats との関係– どちらもメタデータを記述する

– microformats: 軽量で簡易 , 意味を付加するのに向く

– RDF: 汎用的で多機能 , Semantic Web スタックの利

用や、既存 RDF 処理系との相互運用性が必要な場合など

9.1.8 FW 固有の直接化フォーマット• メディアタイプ

– application/xml

• フレームワーク固有の XML 語彙

– Ruby: ActiveRecord– Python: Django– 例 7-4 を参照

• 7 章や 12 章で言及しているように推奨しない– 短期での開発では妥協の余地あり– フレームワーク依存– シリアライズされたデータ構造に過ぎない– 文書ではなくハイパーリンクやフォームを含まない

9.1.9 特別な XHTML• メディアタイプ

– application/xhtml+xml

• 特殊な表現が必要か ?– 既存技術で表現できない正当な理由があるか再確認する

• HTML ファミリ , Atom, RDF, JSON– 問題を正しく捉えていない可能性はないか

• microformats 仕様の作成

– 可能なら公式に提案して相互運用性を確保 (仕様先

行 )– 作成文書に段階的に意味を付加し、その場限りで利用

– microformats Wiki のデザインパターンと命名規則を参照

9.1.9 特別な XHTML• 主要なデザインパターン

– HTML 要素型があればそれを利用

• キー値ペア : dl• リスト : ul, ol• 適するものがない : span, div

– class 属性を指定してタグに追加の意味を付与

• 特に span, div で重要

– 関係の付与

• rel 属性 : このリソースと他のリソースとの関係

• rev 属性 : このページと他のページとの関係

• 関係が対称な場合は rel を使用

– class, rel, rev を説明する XMDP ファイルの作成を検討

9.1.10 その他の XML 語彙• メディアタイプ

– application/xml

• 既存の XML 語彙の利用

– XMathML, OpenDocument, Chemical Markup Language, ...

– Dublin Core, FOAF, ... (RDF アサーションで利用可能

)

9.1.10 その他の XML 語彙

• 独自 XML 語彙の作成– 本書では最後の手段とみなす– 一般には様々な語彙が作成されている

• 本書で言及したウェブサービスのほぼすべてでも

• 技術文化の違い

– microformats は新しく、非公式なものとみなされがち

– 独自 XML 語彙の作成が正当な手段のようにみなされる

– これは勘違い

• スキーマが定義されなければ、 microformats による属性の独自値の導入と同程度

• スキーマ定義は語彙を (名前空間で ) 分類可能にするのみ

• ( 独自語彙の導入という選択を ?) 正当化するものではない

9.1.10 その他の XML 語彙• 適切な技術選択をせよ

– 不必要に独自定義を持ち込まない

• 既存の XML 語彙

• 既存の microformats• 検討中の他の非公式だが有力な候補の利用

– 検討の結果、必要なら独自定義を行なう

• 要素の導入が不要なら microformats の利用を検討

• 要素の導入が必要なら XML 語彙を定義

– この場合に microformats による拡張は不適切

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

9.1.11 エンコーディングの問題• 文字コード変換時の考慮点

– 全てのテキストを UTF-* に変換– エンコーディングが未指定もしくは未知の場合

• 自動検出して変換• 理解不能なものとして拒否

• クライアントとの通信

– XML宣言で encoding を指定– <?xml version=“1.0” encoding=“utf-8”?>

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 宣言でエンコーディングを指定

9.1.11 エンコーディングの問題

• JSON 文書の文字エンコーディング– プレーンテキスト

• 構造化されていない• 文字エンコーディングを指定する方法がない

– このため、 JSON は文字エンコーディングを指定不可能

– RFC4627 では UTF-* であることが規定されている

• UTF-8, BOM付き UTF-16 (, US-ASCII)• 最初の 4 バイトで判別可能

9.2 パッケージ済みの制御フロー

• HTTP 標準応答コード– サーバから提案された制御フロー

• 参考資料– HTTP 1.1 Headers Status Diagram

<http://thoughtpad.net/alan-dean/http-headers-status.gif>– この図の方が 9.2.1, 9.2.2 より有用

9.2 パッケージ済みの制御フロー

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

9.2.3 Atom Publishing Protocol• AtomPub

– HTTP 統一インタフェース上の高水準統一インタフェース

– Atom 文書をエンドユーザに提供することが目的

– 表 9-1: AtomPub リソースとメソッド

• 構成要素– コレクション– メンバ– サービス文書– カテゴリ文書

• AtomPub メンバとしてのバイナリ文書

– URI で識別されるリソースとして同様

4.2.3 GData• GData

– AtomPub の拡張– 新しい種類のリソースを追加– 承認メカニズムのような機能を追加

– Google で働いてないと正確なインタフェースを

サポートすることはない ?• 応用 (AtomPub + GData拡張 )

– Blogger– Google Calendar– Google Code Search– Google Spreadsheets

4.2.3 GData• コレクションの検索

– 追加 : 検索結果のリスト

– コレクションメンバの一部の表現の GET• データ拡張

– Google Calendar の例

• gd:when• gd:who• gd:recurrence

4.2.5 POST Once Exacly• POST の欠点

– 信頼できる HTTP を台無しにすること

– べき等ではないため、何度も送信すると異なる効果

• POE– POST をべき等にするための手段

– HTTP ヘッダに細工をする　 ( 例 p.297)

9.3 ハイパーメディアテクノロジ

• ハイパーメディアフォーマット– リンクとフォームを構造的にサポートするフォーマット

• フォーム– アプリケーションフォーム

• アプリケーション状態の操作• リンクとあわせて本書の「接続性」を実装

• Fielding のいう「アプリケーション状態のエンジンとしてのハイパーメディア」を実装

– リソースフォーム• リソース状態の操作

• GET, DELETE は表現は不要

• POST, PUT には必要なので、それの要求の表現を伝える

9.3 ハイパーメディアテクノロジ

9.3.1 URI Template• kunit さんにパス (w

9.3.2 HTML 4 (XHTML)• ハイパーリンク

– a, link 要素

– href 属性

– rel, rev 属性 : microformats で属性値を拡張

• フォーム

– form 要素

• 欠点

– アプリケーションが表現できる URI には制限がある

– フォームでは GET, POST しか使えない

– クライアントの要求で送信すべき HTTPヘッダを説明不能

– フォームでキー値ペアしか表現できない– フォームで反復フィールドを定義できない

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)

9.3.4 WADL• まにあわなーい