• プログラム：第八回XML開発者の日
• まとめ(議事録)：はてなブックマーク - 第八回XML開発者の日
• まとめ(感想？)：はてなブックマーク - naoyaのブックマーク /xmldevday

• 追加文章：REST でよくある間違い

名字まで(合わせるために)

• リコーの山本さん
  • 資料：yohei-y:weblog: 第八回XML開発者の日
• はてなの伊藤さん
  • 資料：naoyaのはてなダイアリー - 第八回XML開発者の日
• Dinoの舘野さん
  • 資料：川o・-・）＜2nd life - 第八回 XML開発者の日
• インターネットイニシアティブの山田さん
  • 資料：yohei-y:weblog: 山田さんの資料
• SixApartの平田さん
  • 資料：XML開発者の日に参加してきました [dh's memoranda]
• ツインスパークの高橋さん
  • 資料：AjaxによるRESTへの影響
• Mark Baker作成で村田さんプレゼン
  • 資料：直接PDF

RESTはWWWのアーキテクチャスタイル

REpresentational State Transfer

はてなウェブサービスとRESTfulWiki

APIとして見たトラックバックとMT

RSSとAtom Syndication、WebDAVとAtom Public Publishingを比較

AJAXとRESTとの関係

RESTはXML over HTTPではなく、WWWのアーキテクチャスタイル。

例）P2P、MVC、パイプ＆フィルタ、クライアントサーバ

各スタイルは『特徴的な制約の集合から成り立つ』

• 名前のつくありとあらゆる情報
• 全てのリソースは識別子を持つ(URI)
• リソースは状態を持つ
  • 時間や条件とともに内容が変化する
  • リソースの意味は変わらない

RESTはリソースのrepresentational StateをTransferする。

Webブラウザからあるリソースを取得する事を考える。

1. URIをアドレス欄に貼付ける
2. 「移動ボタン」を押すなどしてリソースを取得する

URIを使ってHTTP GETでリソースのその時の状態の表現を取得する。

Webブラウザの場合、アドレス欄にURLを指定するという統一されたインターフェースを利用してリソースを取得する事が出来る。

• 統一されるのはコンポーネント間のインターフェース
• リソースを識別する統一的な識別子の存在

CRUD(Create-Read-Update-Delete)

• GET
• PUT
• DELETE
• POST

リソース同士は単純にURIとHTTPで結びつく。

『URIがあればHTTPでリソースとアプリケーションとの連携が簡単になる』→疎結合

サーバ側でセッション管理の必要が無いため、サーバリソースをすぐに解放できる。→スケーラビリティ

リクエストメッセージは自己記述的である。

cookieやurl-rewritingを利用するとRESTではない。

RESTはUniform Interfaceであるため、インターフェースと目的とがURIで直接結びつく。一方、SOAPはインターフェースと目的とがまとまって結びつく。

URIによってそれぞれの目的が独立する場合、クライアントとサーバの間にプロキシなどを挿む事が出来る。それぞれがまとめられる場合、目的ごとにこれを行う事は出来ない。

Web(URI/HTTP)とサービスが分離

• 全てPOST
• メッセージごとのインターフェース
• メッセージにURI(リンク)が入っていない
  • リンクとして辿る事が出来ない
• HTTPをトランスポートプロトコルとして利用
  • 単純に『送る』ために使う

UIとデータストレージの分離

• マルチプラットフォーム
• スケーラビリティ
• サーバコンポーネントの単純化

サーバー側はステートレスである

リクエストには処理に必要な全ての情報が含まれる。

• ○可視性
• ○信頼性
• ○スケーラビリティ
• ×パフォーマンス低下

同じキャッシュは再利用

• レスポンスがキャッシュ可能かラベル付け
• サーバとクライアントの対話を減らす

コンポーネント間のインターフェースを固定

• ○アーキテクチャがシンプル
• ○可視性が向上
• ○CS実装の独立性
• ×情報粒度によってはトレードオフが発生する

システムの知識を１階層に限る

• ○コンポーネントの単純化
• ○中間子の配置(プロクシ、ロードバランサ)
• ○レガシーシステムの隠蔽
• ×ネットワークオーバーヘッドによる待ち時間

クライアントでコードをダウンロードして実行(Flash, JS)

※RESTではCODはオプション

• ○クライアントを拡張できる
• ×可視性の低下(クライアントとサーバの間)

• RESTはWWWのアーキテクチャスタイル
• RESTでは(URIが意味する)リソースが重要
• RESTを構成する各制約の意味を把握(スペックだけを見ても駄目)
• アーキテクチャスタイルは重要(ソフトウェア技術者の標準スキル？)

ウェブサービス(Web based Service)のターゲットには２種類がある。一般サービスのターゲットであるエンドユーザと、XMLウェブサービスAPIのターゲットになるデベロッパやGeekな人たち。

技術革新を伴うサービスの利用者層推移はハイテクオタクやビジョン先行と行った層が先行する。ビジョン先行層と価格品質重視層との間にはハイテクの落とし穴(Chasm)があり、ここを見落とすと大変。

『技術革新を伴うサービスにとってGeekは重要』

ユーザーがデータをコントロールできる事が大切。

• インポート／エクスポート
• フィード出力
• フィードで過去の物もページングなどでさかのぼる事が出来る
• APIで保存・編集・削除・取得などが出来る

• 他のAPIとの相互互換性
  • はてなのためだけに開発・習得しなければならない事が減る
• 既存ライブラリを利用できる
• はてなとRESTとの相性が良さそう

奇麗なURIを心がける。

O/Rマッパ

テンプレートエンジン

それぞれに特徴的なアーキテクチャ

URIからクラスやメソッドへのdispatch(接続？)に規約(制約)を設ける。

• URI+フレームワークでURI設計に無知でもCool URIを作る事が出来る。
• 『Modelをリソースと見立てて、そのControllerを起動するURIを決定する』ことは自然な流れ。
• URIから対象のクラスやメソッドが分かる
• 結果的にRESTに近づくためREST APIと相性が良くなる

WebAPIを容易に扱える様に、そのアーキテクチャを抽象化する事が重要→標準化

小さなAPIを作るとき

• URIに対して被コメント数を返す
• 大げさ、無理矢理になら可能→どうしたらいいの？

エレメントに対応するデータが直感的でない

• summaryがコメント？titleがタグ？
• 結局仕様書が必要
• 本当にこれでいいの？

サーバー側の実装が面倒→フレームワーク重要

• XML over HTTP
• Basic認証＋野良XML

シンプルで分かり易く、データ項目が明快である。また、小さなAPIも気にせず実装可能。ライブラリもサードパーティ製のものが用意されている(Net:Delicious/Perl)。

• WebAPIを公開する事には意味がある
• REST的なAPIであればAtomPPがいい
• URIとフレームワークは重要

RESTとページングとはトレードオフの関係が発生する場合がある。

AtomPPはAtomで返すために仕様上の制約が発生し、返って邪魔になる場合がある。

はてなダイアリーでは１日の記事を１レコードとしているために、APIにしずらい。

• リソースの名前が明快
• ページに対して誰でもCRUD可能(認証が必要ない)

• URIと内部処理とのマッピングが可能

SixApartが定める仕様

• 参照側から被参照リンクを要求し、被参照側にリーダーからのプッシュで掲載できる
• ブログを中心に、wikiやニュース記事など様々な利用
• REST-likeな実装
• Auto-Discovery(XHTMLに埋め込む)
• RSSへの埋め込み(Draft)
• MetaWeblogAPI
• AtomPP(まだ)

Charsetとして宣言される(MTは未実装)。クライアント側に任せられているため、マルチバイトの場合はUTF-8がお薦め。

• 被参照情報への強いニーズ
• コンテンツホルダーの明確化
• 実装がシンプル

• nofollow、moderation、blacklistで対応
• identification/Authentication(サイトが分散した時の認証など／TypeKeyやOpenID)

MTの位置づけは、ブログではなく『パブリッシング・プラットフォーム』

• tag, filter, callback and action
• Perl API(プラットフォームとしての位置づけ)

MT以前に出来上がったブログはトラックバックをサポートしない

スタンドアロンのプロトコル化したことで、日本でこれだけ流行した

• RSS2.0継承のAtom Syndication
• うりふたつなWebDAVとAtom Publishing Protocol

• 階層化ストレージモデル：WebDAV
• ハイパーリンクモデル：WWW
• タプルスペースモデル：REST
• Uniform Interface：REST, SQL

• 1992　ウェブ誕生
• 1993　writable webは置いてけぼり
• 1996　ウェブオーサリングシステムの乱立
• 1996　標準化
• 1996 - 1998　XMLとの擦り合わせ、POST-onlyにするべきとか試行錯誤
• 1999　RFC2518

• 1999　RSS0.90(RDF)をNetscapeが開発
• 1999　RSS0.91(RDFを破棄)
• 1999　NetscapeがRSSを放棄し、Dave Warnerが引き継ぐ
• 2000　rss-devグループがRSS1.0(RDF)を開発
• 2000　RSS1.0に前後してUserLand版0.91と0.92がリリース
• 2002　MetaWeblogAPIが0.92を取り込む

RDFな人は「RDFで自由拡張」、「セマンティックウェブの第１歩」を主張

DWな人は「オーバーデザインを捨てる」、「安い、早い、旨い最強」を主張

RSS2.0は名前空間に対応するも、RSS2.0の要素は名前空間に所属しないという状態に

Atomは２つの性質を持つ

• Atom Syndication(フィード)
• Atom Publishing Protocol(ウェブリソースのCRUDプロトコル)

• RSS2.0が30要素持つのに対して、Atomは21要素に抑えられている(使わない要素の排除)
• 含める内容をより詳細に規定(機械に易しい)
• １クリック購読が可能(フィード中で流通の身元証明が可能)
• エントリだけを流通させる事が可能(エントリ中でアグリゲーション時の身元証明が可能)
• リソースタイプの記述が可能

• 機能的にはRSS2.3
• RSS1.0/RSS2.0とはっきりした差が無いため、これまでに流通したデータはなかなか消えない
• RDF/RSS/Atomの三国志

Webではデータの合意が重要

• RESTアーキテクチャに従う
• 普通のHTTPでコンテンツを操作できる

WebDAVはHTTP+XML+HTTP機能拡張であるのに対し、AtomPPはHTTP+XML+HTTP用法定義。

階層構造のリソース構成で、各リソースに各自任意のXMLで記述できる属性がついてくる。リソースは親コレクション直下のURI。 (ファイルシステム的オペレーション)

常にリソースの名前が分からないとリソースを作る事が出来ない(クライアントがリソースのURIを知らないといけない)。

フラットなフィードで、再帰的操作という概念が無い。リソースはどこのURIでも許される。

純粋なWebはAtomPPのデータモデル(ハイパーリンク)。

POSTで「無名」リソースを作る事が出来る。

AtomPPはHTTPの枠内で、WebDAVはHTTPを改良したもの。

ただし、世の中にはGET/POSTのみをサポートするHTTPクライアントが存在する(J2ME, Flash)。これをSOAP経由で行うAPIセットがAtomPPに定義されていたが、途中で切り離された。現在は拡張アクセスの手段として考えられている。

結局、目的レベルでは同じである。

「RESTのためにAtomがあるんじゃねぇ、データのためにRESTがあるんだ。」

• 情報の共有や交換が目的
• 連携コストを最小にする

• 共通の合意
• 情報のVisibility+reachability(E2E principle的)
• メタデータ、インターフェースだけの検索は偽物(フルデータよこせ)

• コード界に必要な物はインターフェースとデータ(パラメータと返り値)

データの自動共通理解はHard SemWeb問題(ほとんど無理)

• URIがプロトコル独立を保証する
• インターフェースを隠蔽する

• 「万能」クライアント
  • ウェブブラウザはReadonly→ReadWrite(CRUD)にしてくれる
  • データ種類×アクセス手段の数のクライアントは悪夢
• 今あるデータは参照可能なまま

• 世の中の99%はGETで、残りをPOSTでやっても問題ない(POSTはセマンティック上最強)
• RESTは実装上どうしても苦しいところがある
• インターフェースが細粒度ではない
  • 全てがバルクアップデート
  • 名前フィールドを変えるだけでも全て更新
  • 裏のシステムが複雑になると変更検知が困難
  • 複数のアクセスが連鎖するとき必要なデータが必要以上に増える
• データのネーミングが足を引っ張る
  • データに名前がつかなくてはならない(URI)
  • 全てのデータにabsolute URI

• RESTは強力だけど、実装が大変
• RESTはスケーラビリティのためであって、RESTありきで考えてはいけない
• データ利用をどこまで勝手にスケールさせるか(チェイン)
• REST-friendlyな連携モデルが重要
  • データの合意をとり、ウェブに載せて繋げていく
    • XHTML
    • XML
    • マシン処理可能な物

そうでもあり、そうでもない。

remixingによって、１つのURIに複数のリソースが対応する

XMLHttpRequestによってコードがコネクタとなる(１クライアントに複数のコネクタ)

URIを与える場合の設計指針として

• Server-side representation：URIを与える
• Client-side representation：URIを与えなくても良い

cookieベースで、サーバー側でセッションを管理するためRESTfulじゃない。

アクセスの度に認証を行うためキュリティ的な問題などがある。

リソースごとに認証の必要性を考え、リソースを別々に取得する。認証が要らない場合Cache可能。

AJAXを利用した方がScalable？

認証不要な部分を認証せずに取得できる様になる。

• REST重要
• フレームワーク重要
• 実装大変
• データ(合意)重要
• 課題あり
  • AJAXとREST
  • 認証(Atuthentication&Identification)
• Simple & Sloppy
• RSSはwell-formed？(IE7)

• ブラウザ以外のクライアントを対象にする場合、他のWeb Servicesに比べてRESTは緩め。
• サーバー側でステートを持てないためにリソース粒度が大きくなる

• インターネットスケールでなく、限定されたところで”Web”を実現すると完全なWebができるかも(Wikiとか)
• URIで色々繋がることが大切で、リンク重要

Webは緩やかなリンクしか出来ないため、データを密接に繋げるためにはハードなリンクが出来る空間が必要になる。

• RESTは中央集権
• ビジネスはP2P的
• トランスポートは二の次で、データの標準かが鍵
  • XML over HTTP
  • XML over SMTP

• 基本的に合意は無い
• データ構造はWebに合わせる
• 更新とかはバックエンドで対応

• 中央管理が大事
• ミッションクリティカルな物にルーズな物は使えない
  • どの技術も『ルーズ→しっかり』を繰り返してるからいずれ平気になる？

素直なデータモデルが重要で、シンプルなプラットフォームにする事が重要

XMLスキーマがボトルネック(全てを台無しにする？)

URIの決定など、アプリケーションの指針になる

SEO対策や設計ルールに良い。

GoogleのロボットはCGI実行を嫌うため、?やパラメータを持つURIを嫌がる。クライアントから動的生成を隠す事が重要。

kylix(Linux版Delphi？)を利用して、Apacheモジュール(DSO)が開発可能(速度向上など)。

• 人に分かり易い方がいいか、マシンが分かればいいのか。
• 重要なのは、リソースに対するURIが不変(永続性がある)である事→permalink
• tiny URIを利用して、『知っている＝認証』という構図はどうか(RESTの認証問題)。
• 永続性と可読性のトレードオフ？
• 人向けとマシン向けの２つあると良いかも。