第八回XML開発者の日　RESTとajaxとWeb 2.0 Kawanet Tech Blog/ウェブリブログ

第八回XML開発者の日　RESTとajaxとWeb 2.0

<< 作成日時： 2005/11/25 01:56 >>

eto さんの日記を見て急遽『第八回XML開発者の日』に行ってきた。
http://yohei-y.blogspot.com/2005/10/xml.html
http://www.asahi-net.or.jp/~eb2m-mrt/kaihatsu8.html

XML のナマ村田さんを見れて感激！
http://ch.kitaguni.tv/u/5250/

////////////////////////////////////
【走り書きをメモ残しておく。未整理】

・Atom Format（フィード）→RSS からの改良点
　　・<content type="xhtml" とHTMLフォーマットを明示できる
　　・フィード内にフィード自体のURLが入る？

・コンテンツの階層構造
　　・ワークスペース
　　・コレクション
　　・リソース（HTMLページ等）
　　・エントリ（ブログの記事等）

・WebDAV はリソース全体の一括更新のみだが、
　Atom-PP（Publishing Protocol）では、エントリの更新が可能
　新規の「無名」リソースを追加可能（ブログの記事など）
　
・Atom-PP は、ファイアウォール透過性等、PureHTTP によるメリット

・J2ME／FLASH は、GET＆POST メソッドのみ対応だった！（PUT 非対応）
　　→対策として、Atom-PP in SOAP としてカプセル化する仕様案があった。
　　→でもキャンセルされた

・E2E principle、visibility＋reachability
　　＝データを直接参照できることが大事

・“ハード”セマンティックWEBの目指す「データの意味共通理解」は不可能だろう

・URI がプロトコル独立を保障している

・Read／Write（CRUD＝Create、Read、Update、Delete）

・今はデータ（ソース）がシンプルな現状なので、REST が使えている状態。
　　→データ種別×アクセス手段が増えすぎないように
　　→GET/POST/PUT/…… 足りるの？

・REST でデータを「くっつける」。外のデータもくっつける。
　REST-friendly な連携モデルの構築

・XML は自己記述性が大事
　　→XML ファイル自身以外にリソースフォーク・属性情報がなくても良い。

・マイクロフォーマット
　　→http://d.hatena.ne.jp/naoya/20050715/1121411871

・通信需要の99％は GET メソッド。
　『GET 以外』はすべて POST でいいのでは？（最強のトンネリング）

・高橋さん『REST アーキテクチャ』
　　→REST 本体ではメソッドの規定はない
　　→クッキーはなし（キャッシュさせたい）
　　→WEB 2.0 → remixing・multiple resources

・WEB 1.0 では、URI は単一のリソースを指し示していた
　WEB 2.0 では、URI が複数のリソース

・コンポーネント～～コネクタ～～コンポーネント
　　→connector on demand ← ajax

・サーバ側表現とクライアント側表現を分離

・認証がある時点で REST の限界
　　・ＢＡＳＩＣ認証　＝ダイアログを出したくない。セキュリティ不安。
　　・クッキー　＝サーバ側でステートを持つ必要がある

・WSSE 認証：ユーザ名／セキュリティ・トークン／日時／PasswordDigest
　　→http://d.hatena.ne.jp/keyword/%A4%CF%A4%C6%A4%CA%A5%D5%A5%A9%A5%C8%A5%E9%A5%A4%A5%D5AtomAPI#wsse
　　　サーバ側に生パスワードが必要？

・Web サービス（SOAP等）と Web-based サービスの違い

・『Wiki は盆栽』
　　→WWW の基本はリンク。Wiki も中にリンクを張るのが根幹。
　　　WWW 全体のような森は作れないが、Wiki の盆栽の中は自由に作り込める

////////////////////////////////////
【以下は川崎が思ったこと・質問メモ】

・認証にはSSLが必要なんではないか？SSLだとキャッシュが効かない。
　　→話題にしている REST はそれほどクリティカルでないデータのみが対象。

・参照系：　認証なし、会員認証あり、個人特定あり　等のレベル分け？
　更新系：　これも分けて考える？
　　→レベルごとに認証あり／なしを分解して、キャッシュをできるだけ効かす

・認証をかけつつ、その本人からの GET アクセスのみにキャッシュを効かすための
　テクニックとして、URL の中に個人特定（identification）のための文字列を
　埋め込む仕組みのアイディア。具体的には『乱数名の時限シンボリックリンク』。
　認証自体は別の仕組みで行う。それ以外の個人特定が必要なコンテンツは
　その URL 配下に置くことで、本人にはキャッシュを効かす。
　本人以外にはキャッシュは効かないし、Permament-URI ではなくなってしまうが、
　逆に、一時的な対象個人特定するコンテンツを指定するにはいいかも！

・「REST に適した開発言語は何ですか？」
　　→Ruby（Ruby on Rails）
　　→Perl（はてな）
　　→Java（特に J2ME）がないのは、共通意見！
　　※ただし、rapid プロトタイピングとしてスクリプト系のフレームワークは
　　　非常に有効だが、本当にスケーラビリティが必要な用途には Java も有効。