yohei-y:weblog

Webを支える技術ジュンク堂トークセッション（第4回卓人の部屋）総括

2010-04-10T20:53:00.006+09:00

ブログを書くまでがトークセッションです、と自分で言ってしまった手前書かないわけにはいかなくなってしまったわけです。

第4回卓人の部屋でしゃべってきました。池袋のジュンク堂に行くのは2回目です。前回はRWSのPOPを置きに行ってきました。ジュンク堂の6Fでは高橋会長の本を全力で応援するフェアというのをやっていた。

Webを支える技術 ── HTTP、URI、HTML、そしてREST: 山本陽平; 技術評論社 2010-04-08

とりあえずKPTで振り返ってみました。

Keep: トークセッションを満員御礼にできた; taiさんが来てくれてた; 高橋会長にたくさん話をふった; いろいろな人と名刺交換した; shuyoさんと久々に会った; なんばさんに超久々に会った（そして××な話を聞いた）; yojikさんやshot6さんと初めて会えた; 私服の長田さんに会えた; 発売日に増刷がかかった
Problem: 和田さんに負担をかけすぎた; 開始が15分くらい遅れてしまった; 会場を見回しながら話ができなかった; ちょっと内輪な話をしすぎたか？; もうちょっと穏便な発言をすべきだったような; 話を伝えるのは難しい; 咳しすぎ; レオの質問にちゃんと答えられなかった; オライリーの高さんの前でRWSをDISってしまった; 懇親会で全員とお話できなかった; JSONPは脆弱性だろjk、というコメントにogijunと簡単だからいいじゃんと軽く答えたんだけどもう少しまともに答えられれば良かった; 高橋会長とお話できなかった; POPを書いたのがそこそこ酔っ払ってから
Try: 事前に参加者リストをジュンク堂さんからもらう; 体調管理は万全に; 火曜日に本書の打ち上げがあるのでそこで高橋会長と和田さんとじっくり話す; サインの練習

こうしてみるとProblemばかりですが、twitterやブログでの反応をみると満足してくださった方が多いようなので安心しました。

後から思ったこと。アドレスバーの話。アドレスバーに出現するURIをコピペできるのがWebの疎結合の源泉。だからアドレスバーでURIが表示されてそれを別のアプリにコピペできることはとても重要。これはレオさんの質問(URIでいいの?)に対する答のヒントになるかな。 URIのこのシンプルさと重要性はとても深くて、高橋さんのつっこみのWebのフラットさとかアーレントの件とかにつながるんだろうな。

トークセッション中に言及した書籍やリンクなどをご紹介しておきます。

XML入門―HTMLの限界を打ち破るインターネットの新技術: 村田真; 日本経済新聞社 1997-12

村田さんの本。もう絶版なんだよなー、もったいない。この本はXMLの本なんですが、Webの本でもあります。このころ検討されていたハイパーリンクの話は今読むと実は参考になるかも。

分散システム原理とパラダイム第2版: アンドリュー・S・タネンバウム, マールティン・ファン・スティーン; ピアソンエデュケーション 2009-01-23

分散システムの教科書。ちなみにタネンバウムと共著のスティーン先生のWebページではこの本を使った授業のスライドが入手できます。

楽々ERDレッスン (CodeZine BOOKS): (株)スターロジック羽生章洋; 翔泳社 2006-04-18

リソースモデリングの話は羽生さんのこの本を目指して書いたのですが、とてもここまでは至りませんでした。羽生さんは本当にすごいっす。ERDレッスンはWeb技術者必携の本です。

ウェブ戦略としての「ユーザーエクスペリエンス」―5つの段階で考えるユーザー中心デザイン (Web designing books): Jesse James Garrett; 毎日コミュニケーションズ 2005-02

僕はこの本で情報アーキテクチャを知りました。著者のJesse James GarrettはAjaxという言葉を作った人です。 Amazonのレビューにもあるけど訳がちょっとやばいんですが、薄くてよい本です。

Web情報アーキテクチャ―最適なサイト構築のための論理的アプローチ: ルイスローゼンフェルド, ピーターモービル; オライリージャパン 2003-08

情報アーキテクチャ、ちゃんと学ぶならこちらの本の方がお勧めです。なんですがやっぱり訳が…。なんとかならないのかな、この状況。

最後に業務連絡なのですが、おかげさまで増刷がかかったため、2刷に向けて改訂作業中です。明日(2010-04-11)までにtwitterで#webtechbookをつけてつぶやいてもらえると、収集して反映します。こちらのWikiにまとめ中です。よろしくお願いします

『Webを支える技術 ── HTTP、URI、HTML、そしてREST』という本を書きました

2010-03-03T13:13:00.000+09:00

このブログ、1年近くご無沙汰していました。その間なにをやっていたかというと、実はずっと本を書いていました。『Webを支える技術 ── HTTP、URI、HTML、そしてREST』というなんとも挑戦的な題名の本です。技術評論社さんのWEB+DB PRESS Plusシリーズの11冊目で、来月発売される予定です。

Webを支える技術 ── HTTP、URI、HTML、そしてREST: 山本陽平; 技術評論社 2010-04-08

この本は、WEB+DB PRESSで連載していた「RESTレシピ」という連載がベースになっています。実は連載が1年経ったくらいから、技評さんからは書籍化のオファーをもらっていました。ただ、その時点では書いた分量も少ないし、そもそも自分に雑誌記事とは比べ物にならないくらい分量のある本が書けるとは思っていなかったので、書籍ではなく連載継続という形でトータル2年間連載をしました。

ただ、「RESTレシピ」の連載を続けるうちに、少し疑問に思うことが出てきたのです。「RESTレシピ」は基本的にHTTPやURIの知識を前提に、それらをどうRESTfulに使うか、を解説しようと試みた連載です。HTTPとURIはいわば前提知識でした。しかし、その前提知識を得ようとすると、結構大変なことがわかります。

具体的には本書のレビュアをお願いした高橋さん（高橋さんは同時並行していた文字コード本もレビューしていたそうです。さらに最近監訳本も出てるし…凄いですね！）のこのエントリが詳しいですが、HTTP解説本は現在壊滅的な状況です。僕も学んだ『Webプロトコル詳解』も『HTTP詳説』も絶版なのです。僕が2007年に監訳した『RESTful Webサービス』があるのですが、こちらはHTTPやURIを主題に解説しているわけではありません。オライリーにも英語であれば『HTTP Definitive Guide』がありますが、残念ながら日本語訳は出ていません。

幸いなことに日本にはStudying HTTPという素晴らしいサイトがあります。HTTPやURIの詳しい仕様を知ろうと思えば、このサイトで事足りることも多いです。ただし、Studying HTTPさんはあくまでも仕様の解説であり、その仕様をWebサービスの開発においてどのように実践的に使っていくか、という情報はあまりありません。

ということで、このような状況を打破すべく本を書こうと思い立ったのでした。『Webを支える技術』というタイトルから想像する技術は人によって異なると思いますが、本書で対象としている技術は副題にある「HTTP、URI、HTML、そしてREST」です。ちなみにHTMLは代表例で本書では他のハイパーメディアフォーマット（Atom、JSON）も扱っています。これらの仕様を解説しながら、この仕様はなぜこうなっているのか、どのように使えばいいのか、を本書では解説しています。

目次は以下のような感じです。大きくわけて5部構成で、第1部はWebの歴史とRESTについて、第2部はURIの仕様、第3部はHTTPの仕様、第4部はHTML、Atom、JSONの仕様、第5部はWeb サービスの設計になっています。

◇第1部　Web概論
□第1章　Webとは何か
■1.1　すべての基盤であるWeb
■1.2　さまざまなWebの用途
■1.3　Webを支える技術
■1.4　本書の構成
□第2章　Webの歴史
■2.1　Web以前のインターネット
■2.2　Web以前のハイパーメディア
■2.3　Web以前の分散システム
■2.4　Webの誕生
■2.5　Webの標準化
■2.6　Web APIをめぐる議論
■2.7　すべてがWebへ
□第3章　REST ── Webのアーキテクチャスタイル
■3.1　アーキテクチャスタイルの重要性
■3.2　アーキテクチャスタイルとしてのREST
■3.3　リソース
■3.4　スタイルを組み合わせてRESTを構成する
■3.5　RESTの2つの側面
■3.6　RESTの意義

◇第2部　URI
□第4章　URIの仕様
■4.1　URIの重要性
■4.2　URIの構文
■4.3　絶対URIと相対URI
■4.4　URIと文字
■4.5　URIの長さ制限
■4.6　さまざまなスキーム
■4.7　URIの実装で気をつけること
□第5章　URIの設計
■5.1　クールなURIは変わらない
■5.2　URIを変わりにくくするためには
■5.3　URIのユーザビリティ
■5.4　URIを変更したいとき
■5.5　URI設計のテクニック
■5.6　URIの不透明性
■5.7　URIを強く意識する

◇第3部　HTTP
□第6章　HTTPの基本
■6.1　HTTPの重要性
■6.2　TCP/IPとは何か
■6.3　HTTPのバージョン
■6.4　クライアントとサーバ
■6.5　リクエストとレスポンス
■6.6　HTTPメッセージ
■6.7　HTTPのステートレス性
■6.8　シンプルなプロトコルであることの強み
□第7章　HTTPメソッド
■7.1　8つしかないメソッド
■7.2　HTTPメソッドとCRUD
■7.3　GET ── リソースの取得
■7.4　POST ── リソースの作成、追加
■7.5　PUT ── リソースの更新、作成
■7.6　DELETE ── リソースの削除
■7.7　HEAD ── リソースのヘッダの取得
■7.8　OPTIONS ── リソースがサポートしているメソッドの取得
■7.9　POSTでPUT/DELETEを代用する方法
■7.10　条件付きリクエスト
■7.11　べき等性と安全性
■7.12　メソッドの誤用
■7.13　Webの成功理由はHTTPメソッドにあり
□第8章　ステータスコード
■8.1　ステータスコードの重要性
■8.2　ステータスラインのおさらい
■8.3　ステータスコードの分類と意味
■8.4　よく使われるステータスコード
■8.5　ステータスコードとエラー処理
■8.6　ステータスコードの誤用
■8.7　ステータスコードを意識して設計する
□第9章　HTTPヘッダ
■9.1　HTTPヘッダの重要性
■9.2　HTTPヘッダの生い立ち
■9.3　日時
■9.4　MIMEメディアタイプ
■9.5　言語コード
■9.6　コンテントネゴシエーション
■9.7　Content-Lengthとチャンク転送
■9.8　認証
■9.9　キャッシュ
■9.10　持続的接続
■9.11　そのほかのHTTPヘッダ
■9.12　HTTPヘッダを活用するために

◇第4部　ハイパーメディアフォーマット
□第10章　HTML
■10.1　HTMLとは何か
■10.2　メディアタイプ
■10.3　拡張子
■10.4　XMLの基礎知識
■10.5　HTMLの構成要素
■10.6　リンク
■10.7　リンク関係 ── リンクの意味を指定する
■10.8　ハイパーメディアフォーマットとしてのHTML
□第11章　microformats
■11.1　シンプルなセマンティックWeb
■11.2　セマンティクス（意味論）とは
■11.3　RDFとmicroformats
■11.4　microformatsの標準化
■11.5　microformatsの分類
■11.6　microformatsとRDFa
■11.7　microformatsの可能性
■11.8　リソースの表現としてのmicroformats
□第12章　Atom
■12.1　Atomとは何か
■12.2　Atomのリソースモデル
■12.3　エントリ ── Atomの最小単位
■12.4　フィード ── エントリの集合
■12.5　Atomの拡張
■12.6　Atomを活用する
□第13章　Atom Publishing Protocol
■13.1　Atom Publishing Protocolとは何か
■13.2　AtomPubのリソースモデル
■13.3　ブログシステムを例に
■13.4　メンバリソースの操作
■13.5　サービス文書
■13.6　AtomPubに向いているサービス
□第14章　JSON
■14.1　JSONとは何か
■14.2　メディアタイプ
■14.3　拡張子
■14.4　データ型
■14.5　JSONPによるクロスドメイン通信
■14.6　ハイパーメディアフォーマットとしてのJSON

◇第5部　Webサービスの設計
□第15章　読み取り専用のWebサービスの設計
■15.1　リソース設計とは何か
■15.2　リソース指向アーキテクチャのアプローチ
■15.3　郵便番号検索サービスの設計
■15.4　Webサービスで提供するデータを特定する
■15.5　データをリソースに分ける
■15.6　リソースにURIで名前を付ける
■15.7　クライアントに提供するリソースの表現を設計する
■15.8　リンクとフォームを利用してリソース同士を結び付ける
■15.9　イベントの標準的なコースを検討する
■15.10　エラーについて検討する
■15.11　リソース設計のスキル
□第16章　書き込み可能なWebサービスの設計
■16.1　書き込み可能なWebサービスの難しさ
■16.2　書き込み機能な郵便番号サービスの設計
■16.3　リソースの作成
■16.4　リソースの更新
■16.5　リソースの削除
■16.6　バッチ処理
■16.7　トランザクション
■16.8　排他制御
■16.9　設計のバランス
□第17章　リソースの設計
■17.1　リソース指向アーキテクチャのアプローチの落とし穴
■17.2　関係モデルからの導出
■17.3　オブジェクト指向モデルからの導出
■17.4　情報アーキテクチャからの導出
■17.5　リソース設計で最も重要なこと

◇付録
□付録A　ステータスコード一覧
□付録B　HTTPヘッダ一覧
□付録C　解説付き参考文献

2年の連載（全12回）のベースがあるから比較的楽に書けるよなーと最初は楽観的に思っていたのですが、これが大間違いでしたｗ。はっきりいって原型をとどめているところはほんの少しだけになっています。連載時の原稿は本書の100ページ分くらいだったので、最初はページ数が足りるかどうか心配だったのですが、書いてみたらなんと400ページの本になってしまいました。前付けと後付けを除くと350ページ強なので、2/3を書きおろしたことになります。また、連載時の原稿もかなり修正したり切り貼りしたり、校正したりしてあるのでバグも直っているし文章も読みやすくなっているはずです。

業務連絡：すでにAmazonなどには本書の情報が載っていて、ブックマークもされているのですが2つ変更点をお知らせします。

1つめは発売日についてです。Amazon上は3/18発売になっているかと思いますが、これが諸般の大人の事情で4/8になりました。すでにAmazon等で予約してくださったかたには3週間ほどの延期になってしまいます。申し訳ありません。

2つめの変更点は価格です。発売日延期のお詫びというわけではないですが、10円値下げして2570円+税になりました。なので税込2700円以内で買えるようになりました。それでもやっぱり技術書は高いのですが、技評さんに頑張ってもらいました。

追記(2010-03-07) Amazon上の発売日と価格、そしてタイトルの誤記が直りました。

最後にイベントのお知らせです。発売日の4/8(木)に合わせて、ジュンク堂書店池袋店にてトークセッションをやります。さすがに僕一人で話すのは無理なので、レビュアをお願いしたt-wadaさんにお願いしました。なのでこのトークセッションは自動的に第4回卓人の部屋になる予定ですｗ。

『Webを支える技術』刊行記念トークセッション
日時: 2010年4月8日 19:00～
ジュンク堂書店池袋本店4階カフェにて

なお、ジュンク堂さんでは本書の発売に合わせてフェアもやってくださるそうなので、トークセッションにいらしていただくといろいろ面白い本が一緒に買えると思います。まだ何を話すのかとか全然決まっていないのですが、少しでも面白い話をできるように和田さんと打ち合わせるようにします。よろしくお願いします。

あ、あともう一つ忘れていました。本書の公式ハッシュタグは「webtechbook」になりました。高橋さんの命名です。すでにtwitterでは少しだけ使い始めています。このエントリのタグもwebtechbookにしました。ご愛用ください。それからtogetterにまとめページがあります。このハッシュタグを使ってもらえるとまとめやすくなると思います。

最後に、gihyo.jpでそのうち公開されるはずですが、本書のはじめにから少しだけ引用しておきます。

システムとしてのWebの構造や設計思想、いわゆるアーキテクチャは初期からほとんど変わっていません。最初のWebブラウザと現在のWebブラウザでは実現している機能に雲泥の差がありますが、使っているプロトコルは依然としてHTTPですし、表示しているのは昔も今もHTMLです。Webが誕生してから20年、常に新しい技術が生まれてきました。しかしその基本となるアーキテクチャは同じです。これはアーキテクチャの完成度がとても高いことを示しています。

（中略）

しかし一方で、簡単に接続できなかったり、データを活用するのに特殊なノウハウが必要だったりするWebサービスも存在します。簡単に接続できるWebサービスと、接続するのが難しいWebサービスとの違いはどこにあるのでしょうか。

その答えは「Webらしい設計」にある、と筆者は考えています。サービスをWebらしく作ると、ほかのシステムと簡単に連携でき、将来の拡張も楽になるのです。良い設計のWebサービスは、Web全体のアーキテクチャと調和しています。Webらしい良い設計をするためには、Webのアーキテクチャを理解して意識することが大切です。

　本書は、WebサービスをいかにWebらしく設計するかをテーマとしています。クライアントとサーバはどのように役割分担するのか、望ましいURIとはどのようなものか、HTTPメソッドはどのように使い分けるのか。Webサービスにおけるこれらの設計課題について、現時点でのベストプラクティスを紹介します。このテーマを実現するために、本書は次の2つの目的を持って執筆しました。

（中略）

本書の対象読者は、規模の大小にかかわらずWeb技術を使ったシステムを開発した経験のある人です。本書にはプログラミング言語のコードはほとんど登場しません。なぜなら、アーキテクチャは実装よりも1段階抽象度が高い概念だからです。その代わりに登場するのが、具体的なHTTPのやりとりです。HTTPのライブラリは、ほとんどすべてのプログラミング言語で用意されています。読者のみなさんが得意な言語でどのように実装するかを想像しながら読んでいただけると、よりわかりやすくなると思います。

yokohama.pm で Eventually Consistent の話をしてきました

2009-04-21T06:26:00.000+09:00

先週の金曜日に開催された yokohama.pm で、最近のこのブログのメインネタである CAPとBASEとEventually Consistentについてお話してきました。このネタ、あまり公の場で話すチャンスがないのでこういう機会をいただけてよかったです。ありがとうございました。

CAPとBASEとEventually Consistent

View more presentations from yohei.

最近なにかと忙しくてあんまり更新できませんが、まだ続く予定です。

そんじゃーね

CAPのCとACIDのC

2009-03-17T23:40:00.000+09:00

CAP 定理と BASE の概念を考えたのは UCB の Brewer 先生で、彼は inktomi の偉い人だったというのは前回述べた。

当時のinktomiはYahoo!や Microsoft、それにgooにも検索エンジンを提供していて、1億以上のWebページ(テラバイト級のデータ)を扱っていたようだ。

手元のWEB+DB PRESS Vol.49 のはてなブックマークリニューアル記事によると、現在のはてなブックマークは1160万URLと100GBのHTMLデータ(圧縮済み)を扱っているらしいので、ざっくりいって98年の時点でinktomi は現在のはてブの10倍のデータを扱っていたといってもいい。inktomiで使っていたコンピュータの性能は現在のPCサーバに比べれば1/10程度の性能なので、システム全体でみると現在のはてブの100倍の規模になるだろうか。

結果的には、inktomiのビジネスは失敗し、検索大手の座はGoogleに奪われることになるのだが、Googleに数年先んじてWebのための分散システムを構築することでBrewerはWebスケールの分散システム構築における理論的基盤を獲得するための経験値を得たのだと思う。

彼がこの時点で得た理論的基盤というのがCAP定理と伝統的なACIDトランザクションを緩和するBASEという考え方である。これが2000年の話。

CAPは2002年にMITのSeth Gilbert と Nancy Lynchによって形式化され、晴れて定理となる。CAP定理によれば

Consistency (データの整合性)
Availability (システムの可用性)
tolerance to network Partitions (ネットワーク分断への耐性)

の三つのうち同時に達成できるのは常に二つしかない、ことが明かになっている。

CAP のうち、AとPの意味するところは簡単にいうと以下のようになる。

Availability は分散システムにおけるデータの受給者(簡単にいうとブラウザなどのクライアントのこと)が、常にサービスにアクセス(読込みも、書込みも)できるということを保証する。サーバ側の都合でデータにアクセスできないことがあるとき、そのシステムは Availability を満たしていない。

Partition tolerance は、分散システムを構成するノード(簡単に言うと物理・仮想サーバ)がひとつ壊れたとしてもシステム全体が問題なく動作しつづけることを保証する。システム中のデータを保持しているサーバのうち1台がが物理的にクラッシュしたときに、データの読込みや書込みができなくなったら、そのシステムは Partition tolerance を満たしていない。

残りの一つ、Consistency はACIDのCと混同しがちであるが、両者の定義は違う(ここ重要)。 ACIDトランザクションの文脈での C は、 Wikipediaでは以下のように説明されている。

日本語では一貫性とも呼ばれる。トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保証する性質を指す。つまり、データベースのルール、つまり整合性条件を満たさない状態を起こすようなトランザクションは実行が中断される。

預金残高を例にすると、その値は一般的に0あるいは正の値を取る条件を満たす必要がある。よって、口座Aから送金を行うとき、その前後でAの口座残高が負になるような額を送金することはできないが、これを保証するのが Consistencyの役割である。

これに対してCAP 定理の C は異なる。 CAPの Consistency は、あるクライアントがシステムのデータを更新したら、続いてアクセスするすべてのクライアントが必ず更新されたデータを取得できることを保証するものである。

このconsistency をめぐる混乱は、CAPとBASEの議論をわかりづらくしているように思える。実際に Seth Gilbert と Nancy Lynchの論文では Consistency という言葉は使わずに、 Atomic data object という言葉を使っている(しかしこの Atomic も ACID の Aとは定義が違うので注意!)。

インターネットスケールのサービスでは、必然的に並列処理とノンストップのサービスが求められるので、可用性とネットワーク分断耐性が必須となり、CAP定理に従えば整合性については妥協することになる…

…なる、はずだが現在のWebサービスは、超大規模な分散システムとして運用されているにもかかかわらず、 CAPのC(整合性)も満たした上でA(可用性)とP(ネットワーク分断耐性)を実現しているように見える。

実はいろいろな大規模サイト(Amazon, eBay, Windows Live, ...)が、 CAP/BASE を知ってか知らずか、独自にそれぞれ分散システムを作ってきたら、可用性とネットワーク分断耐性を確保しながら、ある程度の整合性を確保するような分散システムの構築方法について同じような結論を得て、その理論的背景として CAP/BASE がぴったり収まった、というのが面白いところだと思う。

この分散システム構築のノウハウのキーワードとなるのが BASE の E、Eventually Consistent という考え方なのである。

つづく

CAP と BASE について調べたこと

2009-03-03T07:08:00.000+09:00

時系列で

1990年代後半: Eric Brewer (UCB)が inktomi でいろいろ作る
- CAPとBASEの基礎ができる
- http://www.ccs.neu.edu/groups/IEEE/ind-acad/brewer/
2000年7月19日: Eric Brewer が PODC (Principles of Distributed Computing) の基調講演で CAP 定理?と BASE を発表
- CAP は Brewer 予測として知られるようになる
- この時点で、inktomiと同等スケールのWebサービスの問題に対処していた人はあまりいなかったのかもしれない
2002年 MIT の Seth Gilbert と Nancy Lynch が CAP を形式化
- ここで Brewer の CAP が晴れて定理となった
この間、よくわからず
2007年-: eBay の Dan Pritchett が CAP/BASE ベースでいろいろ考える
- Colorado Software Summit 2007
- InfoQ の記事とインタビュー
- QCon 2008
- 2008年1月の ACM Queue に Dan Pritchett の記事(BASE an ACID alternative)が載る
2007年- Amazon CTO の Werner Vogels が Eventually Consistensy 関係でいろいろ
- QCon London でのプレゼン (2007/08)
- Eventually Consistent のエントリ(2007/12)をポスト(日本語訳)
- CACM に Vogels の論文(Eventually consistent)が載る(2009/01)
今ここ

歴史的には Brewer が inktomi の創業者であることが興味深い。

すでに inktomi を知らない人がいるかもしれないけれど、検索エンジンの淘汰の歴史の流れの中で AltaVista と Google の間にいるのが inktomi だ。 inktomiは創業が1996年。Web初期の検索エンジンの座をAltaVistaから奪い、後にYahoo!に買収された。

Wikipedia の記事が詳しいが AltaVista が DEC の Alpha サーバの性能を売りにした scale-up 的アプローチだったのに対し、inktomi は Scale-out 的アプローチを取ったのが(AltaVistaに対する)技術的な成功要因だったようだ。Brewer のスライドの写真を見ると、時期的にはどうやら Sun の UltraSparc II のクラスタを構築していたようだ。これはまさに僕がNAISTの自席で使っていたワークステーションだけれど、CPUが250MHzで640MBメモリを搭載していたと記憶している。

inktomiが取ったこのscale-out戦略ベースのアーキテクチャは今のWebの大規模分散システムの根源となるアーキテクチャとなっている。

つづく

RESTレシピ ―― クールなWebシステムへの道しるべ【最終回】リソースモデリング

2009-02-15T06:11:00.000+09:00

2年間 WEB+DB PRESS で連載してきましたが、今回ついに最終回となりました。正直 REST ネタでこんなにも書くことがあるのかと今でも不思議です。ほとんどコードが登場しないで文字ばかりという異色な連載を載せ続けてくれた編集部さんに感謝です。あと毎回締切ギリギリになってすんませんでした。

ところで最終回のネタですが、連載を始める前からずっと書きたかったリソースモデリングについてやっと書くことができました。まだまだ確立された手法とは言い難いですが、僕なりにまとめてみたものです。みなさんの Web システムを RESTful にするお手伝いができればいいなと思っています。

ありがとうございました。

WEB+DB PRESS Vol.49: WEB+DB PRESS編集部; 技術評論社 2009-02-24

半構造データ、あるいは Web 上のデータ

2008-12-25T02:05:00.001+09:00

国島先生や斉藤先生が XML や半構造データについていろいろ書いてくださっており、それに反応する形ではてなブックマークや twitter 上での議論が日本語で進んでいて面白い。

ブックマークや twitter で細かいコメントを書いているだけでは申し訳ないような気がするので、久々にエントリを書こうとしたのだけれど、なんだかバックグラウンドが長くなってしまった。最先端の研究者のみなさんに失礼な物言いもありますが、XML guy としては XML の話題は釣られるものなのでご容赦ください。

個人的なバックグランド

僕の個人的なコンピュータの原体験は、当時電電公社に勤めていた伯父からもらった PC-8201 である。これはいわゆるハンドヘルドコンピュータで、僕はこれを80年代後半に手に入れた。すでに世の中の流れからは置き去りにされてしまった悲しいコンピュータだったが、N82 BASIC が40文字×8行の液晶で動作して、プログラミングができた。

僕が作ったプログラムは F1 データベースで、歴代のチャンピオンがファリーナ/ファンジオからプロスト/セナまで検索できるものだった。このプログラムはデータとコードと画面がぐちゃぐちゃに入り混じった大変格好の悪いものだったが、それでも自分が書いたプログラムが動作する快感を知ることができたし、何より自分の中では実用的だった。

Web との出会い

PC-8201 のあとはプログラミングへの興味は薄れ、 PC-9801 RX21 でゲーム(A列車で行こうIIIはやりまくったなあ)をしたりしていた程度だったが、94年に大学に入学し、その年の暮に「インターネット」の存在を知り、年明け早々に大学ネットワークのアカウントをもらったことでコンピュータ熱が再燃した。MLも入りまくったし、ネットニュースもさんざんチェックしていた。SunOS4 の上で、NCSA httpd 経由の CGI (JPerl4)でご多分にもれず掲示板を作ったりもしていた。

こんなことを書いてるとおまえは情報系の学生だったのではないかと思われるかもしれないけれど、僕はれっきとした機械工学の学部生で、卒論はロボット(特にScara)のシミュレーションを OpenGL でやっていたりした。

NAIST へ

ロボットの研究はとても面白く、研究室も居心地がよかったのだけれど、一方で自分の中では Web、特にマークアップ言語・構造化文書としての SGML/XML への興味が非常に大きくなってきたため、当時 XML を研究対象にしていた数少ない研究者のおひとりである当時 NAIST (現京大)の吉川先生の研究室に行くことにした。幸い NAIST は大学院大学という特性もあり、情報系以外の学生にも手厚く教育をしてくれ、おもに M1 のときに僕はデータベースシステムについて学んだ。

XML への熱い期待

当時(90年代後半)の XML 業界はある種異常な雰囲気に包まれており、当時世間知らずの田舎学生だった僕の目から見てもアヤシゲなベンダーやコンサルが入り乱れていた(日本国内も、米国も)。それでも毎日 W3C TR のページは必ずチェックし、xml-dev/xml-user を購読し、暇さえあれば XSL(T) のアップデートを追随する毎日を送っていた。

XML勧告直後からは、村田さんという偉大な存在があったこともあり、日本国内でも XML コミュニティが立ち上がった。XML開発者の日というイベントは、昨今の勉強会・カンファレンスブームのさきがけだったと思う。そして、僕はそのコミュニティである程度のポジションを得ることができて、世の中にはすごい人がいるということを実感した。

XML を使う

当時から今まで、僕の基本的な興味のスタンスは変わっていない。僕にとって XML はあくまでも応用ありきである。もちろん基本知識として XML 1.0 のスペックは抑えなければいけないし、最低限 DOM/SAX/XSLT (今なら XQuery か)を使って XML 処理を行えなければならないが、しかし仕様をいくら知っていても、変換プログラムがいくらあっても現実の世界では役に立たないのである。XML で最も重要なのは XML インスタンス、XML 文書そのものであり、スキーマや各種 API はそれを便利に使うための補助ツールでしかない、という意識が僕にはある。

では僕にとって重要な XML 応用は何かというと、当時でいえば XHTML であり、現在はそれに Atom/RSS と microformats が加わったくらいである。もちろん必要であれば docbook を使うし(Markup Technologies99(XML99併催)の論文は docbook で書いた、というより書かされた)、ODF や OOXML も使うのだけれど、自分の中で重要なのは簡単にいえば XHTML と Atom なのである。これは言い換えると Web 上で流通するデータである。

Web とデータベースとデータベース管理システム

Web はデータベースか? この問いに対する答えは人によって異なると思うけれど、僕の答えは簡単だ。Web はデータベースである。しかし、Web はデータベース管理システムではない。

Web には集中管理機構はない。Web はその名の通り世界規模の分散システムであるが、そのアーキテクチャは集中的な管理機構で守られるのではなく、統一インターフェースとアドレス可能性というアーキテクチャスタイル(制約)で形作られている。

つまり Web 上のデータというのは、管理システムの制約から解放され、(RESTの制約にさえ逆らわなければ)自由にただデータとして振る舞うことができるのである。ここが RDBMS 中に格納されたデータと Web 上のデータの一番の違いだと思う。

Web 上のデータは、あらゆるプログラムから独立して生き延びることができる。Web 上のデータはプログラムによって性格を変える。Web アプリケーションを作る人と、検索エンジンを作る人、フィードリーダを作る人が独立して作業を行えるのは、Web上のデータがプログラムから独立しているからである。

データの天動説

XML の最も革新的な一面をあげるとすれば、僕は真っ先に整形式を許したことを挙げたい。XML ではスキーマが明示的に存在しなくても、プログラムからデータを利用可能になったのである。XML 文書に固定的なスキーマはない。これは逆に言うと、一つのXML文書に複数のスキーマを適用してもいい、ということになる。

一つのXML文書に複数のスキーマを適用できるとどうなるのか。それぞれのスキーマごとに、一つのXML文書が違った顔を見せるようになるのである。たとえばあるフィードリーダから見ると単純にサイトの新着情報を通知してくれていたAtomフィードが、OpenSearch 拡張を解釈できる検索アプリから見ると検索結果一覧に見える、といった具合である。

これはすなわち、XML文書はアプリケーションプログラムから独立しており、それはつまり Web 上のデータが持つ特性そのものである(整形式と名前空間でその特性をエンハンスしている)。

Data on the Web と半構造データ

「Web 上のデータ」とさんざん言ってきたのだが、わかる人にはわかると思うけどこれは "Data on the Web" なわけである。僕の意見がどれくらい Abiteboul 先生の意思と被っているのかはわからないけれど、彼の最初の半構造データ論文が "Querying semi-structured data" であり、"Managing semi-structured data" ではなかったのは何かを暗示しているような気がしてならない(単なる思い込みかもしれないが)。

半構造データとは Web 上のデータであり、原理上 Web 上のデータは集中管理できない。なので単一の「管理システム」は存在するはずもない。逆に言うと単一の管理システムで管理できるような XML データは半構造データの文脈を持っていない XML データなわけで、そのようなデータは本来のモデルに基づいて管理するのが正しい姿だと思われる。

連載読んでても楽しめた。子飼弾のアルファギークに逢ってきた

2008-04-11T16:08:00.000+09:00

WEB+DB PRESS 編集長の細谷さんから献本してもらいました。ありがとうございます。

WEB+DB PRESS は毎号もらっているし、弾さんの連載もいつも読んでいるのでそんなに読むところないかなーと思っていたのですが、意外と(失礼!)楽しく読めて、空いた時間2,3時間でさくっと読了しました。

本書の対象読者は弾さんのまえがきに書いてあります。

世界を変えたいあなた、ギークの世界へようこそ。ギークとなる最短の道は、ギークを知ることです。本書はそんなあなたのためにあります。

自分のことを思い出しても、Web に出会って以来、世の中にいるすごい人々に大いに刺激を受けました。本書はそんなソフトウェアエンジニアの入り口に立っている若者(には限らないだろうけど、主に)に読んでもらいたい本です。昔はすごい人と簡単にコミュニケートすることができなかったけれど、今はblogでフラットにつながれるので、本書を読んだら登場人物のブログをどんどんRSSリーダーに追加していくといいですね。そういう新米エンジニアさんが羅針盤的に使える本だと思います。

よかった: 縦書きは良い。読みやすい; 版型も良い。手ごろで読みやすい; きたみさんによる弾さんのインタビューもよかった
もう一歩: 登場する人全員の URI リストがあればよかった。今からでもgihyo.jpでOPMLを提供すればいいのでは; せっかくだから注のインデックスも0からはじめればよかった; 索引もあればよかったような

小飼弾のアルファギークに逢ってきた [WEB+DB PRESS plus]: 小飼弾; 技術評論社 2008-04-15

それにしても弾さんの写真がいっぱいですｗ弾さんファンにはたまらないのではないでしょうか。

RESTful Web サービスの読みどころ: 4章リソース指向アーキテクチャ(ROA)

2008-01-19T14:42:00.000+09:00

t-wada さんも書かれてますが、この4章は本書の一つの山場です。 RESTの制約に基いたWeb技術(HTTP/URI/XML)ベースの具体的なアーキテクチャであるリソース指向アーキテクチャについて説明しています。

先週、池袋のジュンク堂に以下のような POP を置いてきたのですが

この一つ目の質問「URIをメールで送れるのはなぜか?」についての回答がこの章に書いてあります。キーワードは「アドレス可能性」と「ステートレス性」そして「統一インターフェース」です。

Web 上のリソースは URI によって「アドレス可能」となります。すなわち、「このWebページ」とか「この写真」というリソースを URI によって指し示すことができるようになります。 URI をメールに書くためには、このアドレス可能性という性質は必要不可欠です。 URI が発明される以前は、「example.com というサーバの 80番ポートにアクセスして、GETメソッドを /foo/bar というパスに送る」というように自然言語で書かなければならなかったものが、統一的な識別子一つでアクセスできるようになりました。

また、HTTPはステートレスなプロトコルです。ある Web ページを取得するのに、事前条件やセッション初期化などは(基本的には)必要ありません。メールでもらった URI をブラウザのアドレス欄に入れるだけでアクセスできるのはステートレス性のおかげです。

そして統一インターフェースです。たとえ URI があって、ステートレスでも、どのようなメソッドを発行すればいいのかがわからなければ、そのリソースには一生アクセスできません。 HTTP メソッドが固定されているからこそ、URI にアクセスできるのです。

これ意外にも状態の話や表現の話など、盛り沢山ながら比較的ページ数の少い4章は、 REST はだいたい知っているからもっと具体的な設計のことを知りたいよ、という方にピッタリの章だと思います。

RESTful Web サービス: Leonard Richardson Sam Ruby 山本陽平株式会社クイープ; オライリー・ジャパン 2007-12-21

ジュンク堂さんには販促アイテムであるTシャツも飾ってありました。同じTシャツがプレゼント中です。

RESTful Web サービスTシャツプレゼント企画

2008-01-19T00:40:00.000+09:00

RESTful Web サービスのTシャツプレゼント企画を始めました。

http://blogs.ricollab.jp/webtech/2008/01/gifts/

詳細はリンク先を見てください。すでに感想を書いていただいている方ももちろん応募可能です。どしどしご応募ください。

「RESTful Web サービス」は Amazon でずっと在庫切れしていたのですが、やっと復活したようです。池袋のジュンク堂にはこの記事を書いている時点で81冊在庫があるみたいです。なかなか手に入らなかった方もこの機会にぜひ。

ところでジュンク堂といえば、先日池袋店にこの本を宣伝する自筆のPOPを置いてきました。高橋さんに店員さんを紹介していただき、POP用紙まで送ってもらいました。高橋さんすごいっす。

RESTful Web サービスの読みどころ: 3章　RESTfulサービスの特徴

2007-12-20T19:04:00.000+09:00

RWSが本屋さんに並びはじめました。今日外出のついでに神保町に行ってみたら、三省堂は10冊、書泉グランデは16冊も平積みにされていて結構圧巻でした。

今日は3章です。

3章では、きちんと RESTful で広く運用されている数少いサービスの一つである Amazon S3 の ruby クライアントを作りながら、 RESTful な Web サービスの設計とはどんなことなのか、そのサービスのクライアントはどう作るのか、を解説します。

僕は S3 について、これまであまり知らなかったのですが、この章を読んでよく設計されているなー感心しました。もちろん S3 には接続性という、本書で提唱されている ROA に則っていない部分があるのですが、それを差し引いても設計の参考になると思います。特に S3 の認証と認可の仕組みはサービスそのものに課金を考えた場合にとても参考になるでしょう。

RESTful Web サービス: Leonard Richardson Sam Ruby 山本陽平株式会社クイープ; オライリー・ジャパン 2007-12-21

P.S. 3章では ActiveResource の話もありました。

RESTful Web サービスの読みどころ: 2章 Web サービスクライアントの作成

2007-12-17T01:10:00.000+09:00

先週金曜日「RESTful Web サービス」が手元に届きました。こうやって手に取ると実感がわいて嬉しいですね。

写真はこの半年ずっと鞄の中にあってボロボロになってきた原書(右)と金曜に届いた翻訳版(左)、そしてオライリーの中の人からいただいた原書カバーのT-シャツです。

ところで、先日見た働きマンの第9話で、本の出版には様々な人がかかわっていることを再認識しました。著者はもちろん、編集者、印刷所のみなさん、製本所のみなさん、営業担当者配送に関わる方、書店の方々などさまざまな人が関わっているんですよね。こうやって本が出て、実際に書店に並んで買えるようになるのはすごいことだと改めて感じた次第です。

さて、今日ご紹介する2章ですが、この章では del.icio.us のクライアントを様々な言語で作ってみる、という内容になっています。 del.icio.us の API は RESTful じゃないじゃん、というつっこみへの回答は書籍に譲るとして、ここでは苦労話をひとつ。

本書では、ほとんどのサンプルコードは Ruby を使って記述されています。しかし、本章では Ruby, Python, Java, C#, PHP, JavaScript, curl のサンプルコードが、そして ActionScript, C, C++, Common Lisp, Perl のライブラリについての言及がされています。これをチェックするのが結構大変でした。 Common Lisp の HTTP ライブラリは URL が切れていて、編集者さんに原著者に問い合わせてもらったりもしました。

RESTful Web サービス: Leonard Richardson Sam Ruby 山本陽平株式会社クイープ; オライリー・ジャパン 2007-12-21

本書はおかげさまで予約注文が好調なようで、発売前に増刷が決りました。感想や不明点を blog やメールでお知らせいただければと思います。

WEB+DB PRESS Vol.42 と7周年記念イベント

2007-12-14T00:20:00.000+09:00

来週 20 日に WEB+DB PRESS の7周年記念イベントが開催されます。関係者枠で招待していただいたので、僕も参加します。スピーカーがすごい面子で、楽しみですね。連載しててよかった。

ところで次回の WEB+DB PRESS には上記イベントのスピーカーの一人羽生章洋さんと、t-wada こと和田卓人さんと3人で REST に関して鼎談した内容をもとにした記事が特集として載る予定です。

もともとは、編集者さんから、t-wada さんが WEB+DB PRESS を読むときに僕の連載を一番最初に読むと言っていると教えてもらって、僕の方も和田さんの TDD の記事でたくさん勉強させてもらったので(題材が REST だったし)、ぜひ和田さんとお話したいと返信したら、話がどんどん大きくなって羽生さんを交えての鼎談になってしまったのでした。

ビデオ収録の鼎談なんて初めての経験だったのでかなり不安だったんですが、自分の出来はともかくむちゃくちゃ楽しかったです。鼎談の内容はニコニコ動画で公開されるらしいので、お楽しみに。

WEB+DB PRESS Vol.42: WEB+DB PRESS編集部; 技術評論社 2007-12-22

鼎談では URI を Universal Resource Identifier とか間違って喋っていて非常に恥ずかしいので(いつも Uniform か Universal かわからなくなる)、あんまり DIS らないでください。もちろん記事の方は直っています。

それから和田さんが書いてくれた Restlet をベースに RESTful なシステムを実装する章は必見です。 Java じゃない人でも、実際に RESTful にリソースを設計するというのはどういうことかを学べるすばらしい記事になっていると思います。

RESTful Web サービスの読みどころ: 1章プログラマブルWebとWebサービス

2007-12-13T23:33:00.000+09:00

RESTful Web サービスの発売が近付いてきました。

RESTful Web サービス: Leonard Richardson Sam Ruby 山本陽平株式会社クイープ; オライリー・ジャパン 2007-12-21

この章では、いわゆる「Web サービス」の概要を解説します。 Web サービス、およびそれを使って実現されるプログラマブルWebではどのような技術が使われているのか、それらはどのような関係にあるのかがわかると思います。

本書のタイトルでもある RESTful な Web サービスを実現するためには、基本的に HTTP, URI, XML, JSON, (X)HTML, 等の知識が必要ですが、これらの技術を使うだけでは RESTful にはなりません。単なる XML over HTTP が RESTful でないことがしばしばあります。 Web サービスを RESTful たらしめる本質は何なのでしょうか。

本章では「メソッド情報」と「スコープ情報」というキーワードを使い、アーキテクチャで Web サービスを分類することでこの問いに答えています。この二つの情報が、HTTP エンベロープのどこに含まれているかで、 Web サービスは3種類に分類できます(そのうち RESTful なのは一つだけ)。この分類手法は、自分が作った Web サービスが RESTful かどうかをチェックする簡単な手法になると思います。

RESTful Web サービスの読みどころ: はじめに

2007-12-08T00:12:00.000+09:00

すでにオライリージャパンのサイトやメールニュースで新刊情報が流れていますが、以前から何回か紹介してきた RESTful Web Services の翻訳版の監修をさせてもらいました。

すでにさまざまなブックマークサイトで好意的に言及していただいており、とても光栄です。

まだ amazon には掲載されていませんが、12月19日か20日には都内主要書店に並ぶそうです。

追記(2007-12-08) 掲載されました

RESTful Web サービス: Leonard Richardson Sam Ruby 山本陽平株式会社クイープ; オライリー・ジャパン 2007-12-21

そこで、今回から何回かにわたって、発売記念でこの本の「読みどころ」を紹介したいと思います。今回は初回なので、僕が書いた監訳者まえがきから少し引用して、本書全体の読みどころを紹介します。

本書「RESTful Web サービス」は Leonard Richardson と Sam Ruby の二人が世に送る、世界初の REST に関する本格的な解説書です。本書を読めば、REST アーキテクチャスタイルとは何か、それを使ってどのように Web システムを効率的に構築するか、アーキテクチャが RESTful だと何が嬉しいのか、が理解できるでしょう。

(中略)

「はじめに」にもある通り、REST に関する設計ノウハウは、Roy Fielding の博士論文を除けば blog やメーリングリストへの投稿という形でインターネット上に散在している状況です。それらの情報を集めながら学ぶのはとても楽しくためになる作業ですが、REST の普及の観点からは喜ばしい状況ではありません。REST に基づいた Web システムの設計を体系的に学ぶことができるベストプラクティス集が必要とされていたのです。そして本書はまさにそれを実現しています。

目次は以下のとおり。

はじめに
1章　プログラマブルWebとWebサービス
2章　Webサービスクライアントの作成
3章　RESTfulサービスの特徴
4章　リソース指向アーキテクチャ（ROA）
5章　読み取り専用のリソース指向サービスの設計
6章　読み取り/書き込み可能なリソース指向サービスの設計
7章　サービスの実装
8章　RESTとROAのベストプラクティス
9章　サービスの基本要素
10章　リソース指向アーキテクチャと大Webサービス
11章　RESTクライアントとしてのAjaxアプリケーション
12章　RESTfulサービスのためのフレームワーク
付録A　RESTおよびRESTfulリソースの参考文献
付録B　最もよく使用される42のHTTPレスポンスコード
付録C　最もよく使用されるHTTPヘッダー

ちなみに監訳者が付かない本当のまえがきは DHH が書いています(原書は表紙にも DHH の名前が)。こちらも要注目です。

tsupo さんがブックマークでコメントしてくれてますが、12/21のXML開発者の日に本書を持参していただければ、いくらでもサインします :-) (販売の予定はありません...)

第10回XML開発者の日

2007-11-23T23:49:00.000+09:00

今年もXML開発者の日が 12月21日に行われます。今回は XML 色が強いので、一参加者として楽しみです。

REST関係ではgihyo.jp で AtomPub 解説を連載中なあさくらさんに AtomPub の紹介をお願いしました。AtomPub の Interop にほぼ皆勤賞のあさくらさんにいろいろ面白いお話を聞けるのではないかと期待しています。

ステートレスとは何か

2007-10-28T10:45:00.001+09:00

RestWiki をたまに見直すと新たな発見があって面白い。

たとえば先日、「ステートレスなやりとりとは何か(What is Stateless Interaction?)」という箇所を見つけて、興味深く読んだ。このページは以前も絶対に読んでいるはずなのだが、人間は忘れてしまうものである。

RestWiki の例でも充分わかりやすいのだけれど、自分でも例を思いついたので書きとめておく。

ステートフルサーバとステートレスサーバはどう違うのか。

まずは、ステートフルの例:

客: こんにちは
店員: いらっしゃいませ。○○バーガーへようこそ
客: ハンバーガーセットをお願いします
店員: サイドメニューは何になさいますか?
客: ポテトで
店員: ドリンクは何になさいますか?
客: ジンジャーエールで
店員: +50円でドリンクをLサイズにできますがいかがですか?
客: Mでいいです
店員: 以上でよろしいですか?
客: はい
店員: かしこまりました

これはいたって普通の会話に見える。では、ステートレスな場合はどうなのか。

客: こんにちは
店員: いらっしゃいませ。○○バーガーへようこそ
客: ハンバーガーセットをお願いします
店員: サイドメニューは何になさいますか?
客: ハンバーガーセットをポテトでお願いします
店員: ドリンクは何になさいますか?
客: ハンバーガーセットをポテトとジンジャーエールでお願いします
店員: +50円でドリンクをLサイズにできますがいかがですか?
客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします
店員: 以上でよろしいですか?
客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします。以上
店員: かしこまりました

これは明らかに冗長であほらしいのだけれど、サーバがステートレスというのはこういうことである。

ステートフルの例では、2回目以降の対話では、客(クライアント)はそれまでの前提(ハンバーガーセットを頼んでいること)は繰り返さなくてもよかった。なぜか。それは店員(サーバ)が客(クライアント)の注文状態を覚えていたからである。この店員(サーバ)は「この客(クライアント)はハンバーガーセットをポテトで頼んでいる」ということを覚えている。これをアプリケーション状態、あるいはセッション状態と呼ぶ。次にドリンクの種類を聞いたときに店員(サーバ)は自分で覚えている客(クライアント)のアプリケーション状態を「この客はハンバーガーセットをポテトとジンジャーエールで頼んでいる」と更新する。

ファーストフード店の店員であれば、ステートフルな実装は当たり前なのだが、Web サーバは異なる。それはスケーラビリティの問題である。店員(サーバ)が一人の客(クライアント)をずっと相手にしていると、その間別の客に対応することができない。店が込んできたら(アクセスが集中したら)、店員を増員して(Webサーバを増設して)対応する。普通の店舗では、ひとつのレジで一人の店員がずっと同じ客を受け付けるのだが、 Web の場合は複数の Web サーバ(比較的少数)で複数のクライアント(比較的多数)を同時に受け付ける。ここで、ステートレスサーバであれば、以下のように、各インタラクションで別々の店員(サーバ)が客(クライアント)の注文(リクエスト)に応答(レスポンス)することが可能になる。

客: こんにちは
店員1: いらっしゃいませ。○○バーガーへようこそ
客: ハンバーガーセットをお願いします
店員2: サイドメニューは何になさいますか?
客: ハンバーガーセットをポテトでお願いします
店員3: ドリンクは何になさいますか?
客: ハンバーガーセットをポテトとジンジャーエールでお願いします
店員4: +50円でドリンクをLサイズにできますがいかがですか?
客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします
店員5: 以上でよろしいですか?
客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします。以上
店員6: かしこまりました

ステートレスサーバというのは一見冗長なように見えるが、スケーラビリティの観点から見ると、理に適っているものである。

合わせて読みたい: A Web-Centric Approach to State Transition

AtomPub が RFC 5023 に/日本語訳を公開します

2007-10-12T18:18:00.000+09:00

AtomPub がついに RFC になりました!

関係者のブログ

Joe Gregorio: RFC 5023 - The Atom Publishing Protocol
Sam Ruby: <appdraft>no<app:draft>

RFC になるまでずいぶんと長かったように感じますが、その分完成度は上ったのだと思います。 interop もすでに何回も開催されており、その結果も良好です。

AtomPub は全ての、とはいかないまでも、多くの Web サービスのベースとなることができるプロトコルです。たとえば blog 、何らかのデータベース、画像/映像リポジトリ、 Wiki、カレンダー、ソーシャルブックマークなど、title/author/updated というメタデータがあって、その読み書きができるサービスは全て AtomPub ベースの API を出せる可能性があるでしょう。

さて、そんな AtomPub を会社の同僚と翻訳したので、公開したいと思います。

draft-15 から翻訳を始めたので、比較的長い時間レビューしていますが、それでもミスや変なところがある可能性はあります。もし何か問題があれば、ご連絡ください。

AtomPub 実装者の方々の一助となれば幸いです。

追記: 技評さんが gihyo.jp で取り上げてくれた

さらに追記(2007-10-21): WEB+DB PRESS の連載で AtomPub を取り上げています。今月発売の Vol.41 では AtomPub で導入されたサービス文書やメディアエントリの解説をしています。

WEB+DB PRESS Vol.41: WEB+DB PRESS編集部; 技術評論社 2007-10-24

コレクションとエントリの基本を解説した Vol. 40 と合わせてどうぞ。

WEB+DB PRESS Vol.40: WEB+DB PRESS編集部; 技術評論社 2007-08-24

ちなみに Vol. 41 では RFC 5023 という番号を紙面に入れることができました。正にぎりぎりの修正だったのですが、間に合ってよかった。

REST の勝利宣言と良い XML の見分け方

2007-09-08T14:56:00.000+09:00

ITpro Challenge 行ってきました。

豪華なメンバーでどの講演もとても面白かったですね。江島さんの講演は、Web 上でサービスをやるとはどういうことなのかについてとても示唆に富んだ話だったし、鵜飼さんのハッカーのソフト工学の話は職場的にすげータイムリーだったし、なおやさんの話は同時代を生きてきた、生きている者としてとても共感できる内容だったし、戀塚さんはこれぞハッカーという感じのすごい人でした。

僕は LT の最後に話をさせてもらったわけですが、ネタを二つ持っていって聴衆のみなさんに選んでもらうことにしました。

結果は REST が勝ったので、当初の予告どおり REST の話をすることに。

結局お蔵入りになった XML の話ですが、もったいなかったので懇親会でお話させてもらいました。

プレゼン中で引用した Web ページはこちらです。

檜山さんの記事

Tim Bray の記事

リンクは重要ですよ。

いろいろ改め AtomPub の話と、パターンの話と、消費電力の話と、古くて新しい開発環境の話と、Tim Bray のインタビューと、Dave Thomas のTシャツプレゼントが載ってる WEB+DB PRESS Vol.40

2007-08-20T23:07:00.000+09:00

WEB+DB PRESS の Vol. 40 が届きました。どうもありがとうございます。

僕は Atom API 改め AtomPP 改め APP 改め AtomPub/Atompub な Atom Publishing Protocol の解説を REST の連載で書きました。記事のドラフトではずっと APP で通してきたのですが、最後の最後で AtomPub に切り替えました。いろいろ考えたんですが AtomPub で統一して呼んでいこうかと。

今回は 40号記念だからか、すごく充実した内容です。パターンの特集はここまでまとまってるのは今までなかったし、サーバの消費電力の話なんて、他にどこで読めるのかわからないような記事でした。僕はどちらかというとソフトウェアの抽象レイヤをいつも考えているので、たまにこういう物理的な話を読むととても勉強になります。

それにしても id:naoya 氏はどんだけ記事書いてるんだと小一時間問い詰めたい。はてなのCTOはよっぽど暇なのかそれとも文章書くのが速いのか。まあどう考えても後者ですよね。

…という微妙な DIS はともかく、新人さんとか向けに古くて新しい unix 開発環境を整えさせるにはとてもよい導入記事だと思います。

それからなにげにニュースのところに Tim Bray のインタビュー記事が載ってますが WADL どうよとか聞いていてよいですね(自作自演)。ちなみに僕は WADL いらない派です。

そしてなんといっても Dave Thomas (とプレゼントの Tシャツ)でしょう。僕もこれから応募はがき書くところです。メッセージがまたかっこいい。Tシャツ画像はひろせさんのところで見れます。プログラミングはやっぱり楽しくなきゃいけないですね。

WEB+DB PRESS Vol.40: WEB+DB PRESS編集部; 技術評論社 2007-08-24

APP の標準化作業がほぼ終了

2007-07-25T21:45:00.000+09:00

Tim Bray からアナウンスがあったとおり、 APP の標準化作業がほぼ終了しました。 RFC 番号が付くのはしばらく先だと思いますが、現状の仕様を実装してもう問題ありません。最後の draft-17 ベースの仕様が RFC になります。今後の修正は editorial なものだけのはずです。

この先、Web API を設計する人は、まず APP が利用できないか検討しましょう。 APP を採用すれば自然と REST スタイルを採用することになります。これまで悩みがちだった Web API の設計が、かなり楽になると思います。 Web API を設計する人は、オレオレXMLを設計する前に、Atom/APP をベースにしたらどうなるか、を考えて見ましょう。きっと Atom/APP は良い選択肢になってくれるはずです。

日本では AtomPP で定着しつつあった Atom Publishing Protocol の略語ですが、 Tim Bray のエントリにあるとおり、 Atom プロトコル、APP、Atompub があちらでは標準的な略語になりつつあります。とりあえず AtomPP と呼ぶのはやめたほうが、相互運用性の観点から望ましいと思います。

来週月曜には、APP の Interop が日比谷であります。日本でも APP を盛り上げていきたいですね。

APP Interop in Tokyo

2007-07-20T22:20:00.000+09:00

NTT コミュニケーションズの朝倉さん(実は NAIST の研究室の先輩です)と一緒に 7/30 に Atom Publishing Protocol の接続試験を東京で行います。

http://intertwingly.net/wiki/pie/July2007InteropTokyo

4月に Google Campus で行われたものの日本版です。今のところ参加する予定なのは

あさくらさん(ntt.com)
丸本さん(ウィザ)
shigeta さん
miyagawa さん(リモート)
たけまるさん
我々

参加されたい方は上記 Wiki に名前を書く、あるいは僕(yoheiy at gmail dot com)までメールください。APP の実装をお持ちの方はぜひ。

[これはすばらしい] mixi ステーション API。ただ一つ注文が…

2007-06-29T21:50:00.000+09:00

via: mixi あしあとAPI発掘

mixi が Atom Publishing Protocl (APP) 対応の Web API を mixi ステーションで利用しているそうだ。

さっそく手元にあった APP クライアントで試してみると 30分くらいであっさりと接続成功。本当に素晴しい。ざっくりと Web API を見させてもらったのだけれど、拡張タグの使い方などセンスが良いし、さすがという感じだ。

ただ一点だけ、どうしても直してほしいのは APP の service document の名前空間 URI。これは http://www.w3.org/2007/app が本番仕様である。mixi の Web API は古い名前空間を使ってる。中の人はわかっていると思うんだけど、APP はもう少しで RFC になる。 APP を実装する人は必ず RFC になる名前空間 URI を実装しましょう。 mixi の API を真似している人は気をつけてね。

HTTP ステータスコードを正しく使おう

2007-06-18T18:35:00.000+09:00

先月、ぐるなび API がリリースされていました。ぐるなびさんの持っている膨大なデータベースに Web API を通して気軽にアクセスできるようになったのは、非常に喜ばしいし、その英断に感謝したいと思います。

しかし、Web API 仕様書、特にエラー仕様を見てちょっとがっかりしました。もう少し上手にデザインすれば、もっとよかったのに…、という思いです。

一度出してしまった API はそう簡単に変えられないと思いますが、参考までに僕だったらどうするか、を書いてみます。

この仕様の一番の問題はエラーコードです。以下は 2-2 のエラー仕様に記述されているサンプルです。

<?xml version="1.0" encoding="UTF-8"?>
<gnavi>
 <error>
   <code>602</code>
 </error>
</gnavi>

タグが三つ(gnavi, error, code)出てきます。重要なのは code だけで、ここにエラーコードが入ります。 602 というコードは Invalid Shop Number を示します。エラーコード一覧を見ると、現在五つのコードが定義されていることがわかります。

よくない点を一言で言うと、エラーコードを再発明してしまっているということです。たとえば 604 は "Internal Server Error" なんですが、このフレーズに覚えがありませんか? そう HTTP の 500 Internal Server Error と同じです。HTTP で 500 を返せばいいところを、独自 XML 形式でしかも 604 という独自のエラーコードを再発明しています。

HTTP/1.1 200 OK
Content-Type: application/xml

<?xml version="1.0" encoding="UTF-8"?>
<gnavi>
 <error>
   <code>604</code>
 </error>
</gnavi>

本来はこうあるべきです。

HTTP/1.1 500 Internal Server Error
Content-Type: text/plain; charset=utf-8

処理中にエラーが発生しました。

なぜエラーコードの再発明は駄目なのでしょうか。それは専用のクライアントが必要になるからです。単なる HTTP クライアントではなく、ぐるなびのエラーコードを実装した専用クライアントが必要になってしまうからです。専用クライアントが必要なので、その分余計なコードが必要となって、障害が発生する確立も上ります。

参考までに、ぐるなび API のエラーコードを HTTP のステータスコードにマッピングしてみました。

gnavi エラーコード	HTTP ステータスコード
600 NoShop	404 Not Found
601 Invalid Access	403 Forbiddden
602 Invalid Shop Number	400 Bad Request
603 Invalid Type	400 Bad Request
604 Internal Server Error	500 Internal Server Error

601 は通常は 401 Unauthorized にしたいところですが、ぐるなび API は api key 方式を採用しているので 403 にしてみました。また、この対応により 602 と 603 が 400 にまとめられてしまっていますが、両者の違いは HTTP のレスポンスボディで記述すればいいでしょう。もし、この二つを区別する理由が、エラーメッセージを出すためだけであれば、メッセージそのものをプレーンテキストで返せばいいのです。

HTTP/1.1 400 Bad Request
Content-Type: text/plain; charset=utf-8

指定された店舗の情報が存在しません。

HTTP/1.1 400 Bad Request
Content-Type: text/plain; charset=utf-8

不正なぐるなび店舗IDパラメータが指定されました。

WEB+DB Press の今月号には、まさにこの話を書きました。本文とコラムが同じくらいのページ数という、一時期の JavaWorld の檜山さんみたいな構成ですが、普段なにげなく使っている HTTP のステータスコードは Web API を作る上でどうあるべきか、という話です。

WEB+DB PRESS Vol.39: WEB+DB PRESS編集部; 技術評論社 2007-06-22

Restful Web Services

2007-04-25T20:16:00.000+09:00

以前言及したオライリーの REST 本 Restful Web Services が Amazon で予約可能になっていました。

この本、とても素晴しい内容です。レビュアに応募して原稿を見せてもらったのですが、 REST に関する ABC が一通りつまっていて、何が RESTful なのかについてしっかりと書いてあります。

RESTful でないことについてもちゃんと記述があって、 xml-rpc とか POX over HTTP とかも出てきます。また、アーキテクチャの面からはRPC(SOA)とREST(ROA)の違いもあったはず。

Ruby (Sam Ruby じゃなくてプログラミング言語 ruby)のコード例なんかも載っていて読む価値十分です。

残念ながら原稿を読むのに時間がかかり過ぎて、後の方の章にした僕のコメント(文字コードとか)は反映されてないみたいなんですが、REST を体系的に学びたい方には超おすすめの1冊です。

Restful Web Services: Leonard Richardson, Sam Ruby; Oreilly & Associates Inc 2007-05

WEB+DB PRESS Vol. 38

2007-04-19T23:18:00.000+09:00

WEB+DB PRESS Vol. 38 で REST 周りのことについての連載を始めました。

ちょうど1年前に REST の解説を書いたんですが、その直後に naoya さんが連載で、と書いてくれてそれを見た技評の中の人が mixi で「連載しませんか」というメッセージくれたんだけど、ちょっと1年続くネタに困りそうなのでやんわりと断ったのでした。んで、1年後、技評の中の人がもう一度話を持ってきてくれて、今年は APP もついに RFC になりそうだし、連載してもいいかなーと思って連載することにしました。ということで何が言いたいかというと、naoya さんの影響力と技評の中の人の企画力はすごい、ということでした。

肝心の今回の内容ですが、円グラフで表現すると、こんなかんじです。

WEB+DB PRESS Vol.38: WEB+DB PRESS編集部; 技術評論社 2007-04-24

Dr. Jim Gray がヨットで行方不明に

2007-01-30T20:21:00.000+09:00

Amazon CTO の Werner Vogels のブログから。データベース界の偉人、マイクロソフトリサーチの Dr. Jim Gray がヨットで航海中に行方不明になっているとのこと。

心配です。

S はシンプルの S

2007-01-23T23:21:00.000+09:00

This entry is a Japanese transration of Pete Lacey's "The S stands for Simple".

Burton グループのアプリケーションプラットフォームサービスグループでは、 REST派とSOAP派の間でずっと継続中の議論がある。その大部分は外部での議論によく似ている。最近のやりとりの一つ、 SOAP と Web サービスフレームワークの複雑さの議論で、 SOAP 側は「WS-* の前は、SOAP は実際にシンプルだった。S はシンプルの略だ」といった。

さあ歴史を学ぼう。 2000年、悩める開発者が問題をかかえている。

開発者: うちの上司が先週末ゴルフをやってきて、いわゆる SOAP なエンタープライズをやる必用があるんです。でも私は SOAP が何なのか知りません。教えてもください、 SOAP の人。

SOAP の人: もちろんです。まず、SOAP は「シンプル・オブジェクト・アクセス・プロトコル」の略なんです。

開発者 シンプルなんですね?

SOAP の人: 日曜日のようにシンプルですよ

開発者 オーケー、教えてください。

SOAP の人 はい、その名前のとおり、SOAP はリモートオブジェクトにアクセスするのに使います。

開発者 CORBA みたいなもの?

SOAP の人 シンプルなこと以外はまさに CORBA に似ています。ファイアーウォールを通過できない複雑なトランスポートプロトコルの代りにHTTP を使います。そして、バイナリメッセージフォーマットの代りに XML を使うのです。

開発者 面白いですね。どのように動作するのか教えてもらえますか?

SOAP の人 もちろんです。まず、SOAP エンベロープというのがあります。これは非常にシンプルです。 SOAP エンベロープはヘッダとボディで構成される XML 文書なんです。そしてボディには RPC コールが書けます。

開発者 SOAP は RPC なんですか?

SOAP の人 そのとおりです。さきほど述べた通り、SOAP ボディにメソッド名と引数を埋め込むことで PRC コールが作れます。メソッド名は一番外側の要素でその子要素がパラメータです。そして全てのパラメータはこの仕様書の第5節の定義に従って型を持ちます。

開発者 (第5節を読む) オーケー、悪くないですね。

SOAP の人 そして、サービスを配備したら、エンドポイントを指定します。

開発者 エンドポイント?

SOAP の人 エンドポイントはサービスのアドレスですよ. SOAP エンベロープをエンドポイントの URL に POST するんです。

開発者 エンドポイントの URL を GET したらどうなるんですか?

SOAP の人 わかりません。GET の利用は定義されていないんです。

開発者 ふーむ。でももしサービスのエンドポイントを別のエンドポイントに移動したらどうなるんですか? 301 が返されるんですか?

SOAP の人 違います。SOAP は実際には HTTP のレスポンスコードは使っていないんです。

開発者 つまり、SOAP が HTTP を使っているというのは、 HTTP 上をトンネルしているという意味ですか?

SOAP の人 はい、トンネルはちょっと悪い言葉ですけどね。SOAP はトランスポートを意識しない(transport agnostic)と言った方が良いですね。

開発者 でも HTTP はトランスポートじゃなくてアプリケーションプロトコルですよね。まあとにかく、SOAP がサポートしている他の「トランスポート」には何があるんですか?

SOAP の人 えーとですね、公式にはありません。ただ、どんなトランスポートも潜在的にはサポート可能です。そして、JMS や FTP や SMTP をサポートしたプラットフォームがたくさんあります。

開発者 誰かそれらのトランスポートを使っている人はいるんですか?

SOAP の人 うーん、いません。でも重要なのはそれができる、ってことなんですよ。

開発者 そうですか。ところでこの SOAPAction ヘッダというのは何のためにあるんですか?

SOAP の人 正直に言えば、誰も知りません。

開発者 じゃ、この "actor" とか "mustUnderstand" 属性というのは? 誰かこれを使っている人はいますか?

SOAP の人 いいえ。誰も使ってません。とりあえず無視してください。

開発者 わかりました。やってみます。

(時間の経過)

開発者 えーと、一つの SOAP スタック上だけでなら、だいたい動くようになりました。あと RPC とオブジェクトのシリアライズはどうも好きになれません。

SOAP の人 RPC! オブジェクトのシリアライズですって! SOAP が RPC だなんてどこで影響を受けたんですか? SOAP はドキュメントベースのメッセージングですよ!

開発者 え、でもたしかあなたがそう…

SOAP の人 私が何て言ったかなんて忘れてください。これからは大粒度メッセージをやりとりするんです。いいでしょ? 大粒度って言葉。メッセージは XML スキーマに従ったものです。この新しいスタイルは document/literal って言うんです。あ、古いのは RPC/encoded ね。

開発者 XML スキーマ?

SOAP の人 大流行してるんです。次はこれですよ。見てみてください。

開発者 (XMLスキーマ仕様を読む)。天よ、お助けください! アレクサンドロス大王でも解けないよ、こんなの。

SOAP の人 心配しないでください。ツールがあなたのためにスキーマを作ってくれるんです。本当ですよ。これは全部ツールがやってくれるんです。

開発者 ツールはどうやってスキーマを作るんですか?

SOAP の人 はい、ツールは(可能なら)あなたのコードを反映したスキーマを自動的生成します。

開発者 私のコードを反映するんですか? オブジェクトのシリアライズではなくて、ドキュメントなんじゃないんですか?

SOAP の人 私の話を聞いてなかったんですか? 全部ツールがやってくれるんです。とにかく、あなたが手で XML スキーマと WSDL (ウィズドゥール)を書くとは期待していません。さらに、これは配管工事なんです。これを見る必用はないんです。

開発者 ちょっとまったー。ウィズドゥール? 何それ?

SOAP の人 あれ、まだ WSDL の説明をしてませんでしたっけ? ダブリュ・エス・ディー・エル、Web サービス記述言語です。クライアント開発者がアクセスするサービスのデータ型やパラメータ、オペレーション名、トランスポートバインディング、エンドポイント URI を指定できるんです。ほら見てください。

開発者 (WSDL 仕様を読む) これ書いたやつ逝ってよし。内部矛盾してるよ。あとこの HTTP GET バインディングって何さ。 GET は未定義じゃなかったの?

SOAP の人 気にしないでください。誰も使ってませんから。とにかく、ツールが WSDL を生成してくれて、WSDL に XML スキーマも含まれているんです。

開発者 しかしそれは逆であるべきじゃないんですか? 最初にコントラクトを設計してそれからコードを生成するべきではないんですか?

SOAP の人 はい、ええ、原理上はそうだと思います。でも、それをやるのは簡単ではないんです。それと WSDL を最初に作る開発手法をサポートしている SOAP スタックは少いんです。それはツールにやらせてください

開発者 もう一つ質問。 XML スキーマに適合したメッセージをやりとりするなら、オペレーション名はどこで指定するんですか?

SOAP の人 はい、SOAPAction HTTP ヘッダは覚えておられますか? みんなそこにオペレーション名を書いています。

開発者 みんな?

SOAP の人 はい、この新しいスタイルは実はまだどこにも記載されていないんです。

開発者 うーんおたくの業界はしょっちゅうあいまいで間違ってて確実に標準化されていない仕様で構築されてるのに注意しないとなー。実際、SOAP と WSDL 仕様はただの W3C Note であってワーキングドラフトでもないじゃないですか。

SOAP の人 今頑張っているところです。

開発者 これで相互運用性が得られるんですか? 約束してもらえますか?

SOAP の人 もちろんです。

開発者 試してみます。

(時間の経過)

開発者 なんてこった。俺のツールで生成した WSDL はお客様が使っているツールでは読み込めなかったよ。それだけじゃない、スキーマはわけかわらないし再利用できないじゃないか。それに SOAPAction ヘッダの扱いを合意しているツールなんてないみたいだし。

SOAP の人 御愁傷様です。ただ救われるのは、もうだれも doc/lit スタイルを使っていないことです。トランスポート独立にするために、wrapped-doc/lit をみんな使っているところです。 wrapped-doc/lit ってかっこよくないですか?

開発者 何それ?

SOAP の人 はい、wrapped-doc/lit は doc/lit に似ているんですが、メッセージ全体をオペレーション名と同じ要素でラップするんです。オペレーション名はメッセージに戻ってきました。

開発者 オーケイ、仕様はどこですか?

SOAP の人 あ、仕様はありません。これはマイクロソフトがやろうとしているらしいことです。いいアイデアなので、賢い子たちはみんなこうやってますよ。それに、新しい話もあるんです。きっと気に入ると思います。 Web Service Interoperability Group、またの名を WS-I って言うんです。彼らがやろうとしているのは SOAP と WSDL 仕様のあいまいな部分をとりのぞくことです。仕様がお好きなことは知ってますよ。

開発者 それは言い換えると、仕様が非常に悪かったので、標準を標準化するための標準化団体が必用だったということですね。なんつーか。で、WS-I は相互運用性問題を解決してくれるんですか?

SOAP の人 ええ、そうです。 WS-I に適合した SOAP スタックを使って、 XML スキーマの80%を回避して、変なデータ型を使わずに、そして WebSphere と Apache Axis での動作を考えなければね。

開発者 つーか wrapped-doc/lit はそこで説明されてるんですか?

SOAP の人 えー、されないです。でも問題ないです。ツールは理解してくれますから。とにかく、ほとんどは。

開発者 まとめるとこうですか。 SOAP の定義は不安定で、SOAP は全然シンプルじゃなくて、それは全てのツールがまだしていることだけれど、もはやオブジェクトにアクセスという意味はないってことですね。

SOAP の人 だいたい正しいです。ただ我々は一歩先を行っています。 SOAP の略語の意味を廃止したんです。

開発者 えー! 何の略になったんですか?

SOAP の人 何の略でもないんです。

開発者 (ﾟДﾟ)ハア?

SOAP の人 UDDI について説明させてもらえますか?

Duncan Cragg の最近の REST/SOAP 関係のポストに、対話形式を使うのを先を越されてしまった。このうぬぼれはソクラテスの時代から使われてきたという事実を勇気を持つ材料にしよう。

[図解]東京の地下技術

2006-11-30T00:10:00.000+09:00

思わず [これはすごい] タグを付けたくなる内容の本だった。

そもそもなんで自分の Amazon のおすすめリストに入ってきたのかわからないんだけれど、たぶん鉄関係の本をチェックしているからなんだろう。

本書は書名のとおり東京を例に、土木技術(特に地下および超大規模構造物)を平易な文章と豊富なイラストで紹介したものである。専門家には当たり前すぎてつまらない内容なのかもしれないけれど、建築初心者の僕には丁度よかった。

たとえば東京港臨海道路のトンネル部は4万トンの重さのトンネルブロックを11個、それぞれ海に浮べて引っ張っていき、海に沈めて連結してできた全長1.3km のトンネルである、というような一般人の想像をはるかに越えた現実を知ることができる。いったいどうやって4万トンの物体を海に浮べるのか、そしてそれをどうやって沈めるのか、その手法は知ってしまえば確かにそのとおりと思うのだけれど、それを想像できるかというと僕には自身がなかった。

本書を読むと、トンネルや地下施設というのはそれぞれがオーダーメイドなのだ、ということがよくわかる。シールド機はトンネルにあわせて特注のものが作られるし、その土地の土壌や地盤の性質、あるいは周辺の環境に併せて適宜工法が選択・開発される。

これはやっぱりソフトウェア開発でいうところのデザインパターンや開発手法に近いな、と思った。ソフトウェア開発手法に興味があるのなら、建築関係の本を読むのはやっぱり必要なのかも。

図解東京の地下技術―地面の下は「知」の結集、「技」の競演!: 青山ヤスシ古川公毅; かんき出版 2001-12

第九回XML開発者の日終了

2006-11-24T23:20:00.000+09:00

無事終了しました。

プレゼンは secondlife さんのプレゼンツールをカスタマイズして使わせてもらいました。ありがとうございました。はてな記法なんで、はてなダイアリーに置いておきます。

第九回XML開発者の日

2006-11-07T23:47:00.000+09:00

11月24日に、昨年と同じ新富町の印刷会館で第九回XML開発者の日が開催されます。現時点で六つの発表が予定されていますが、あと一つか二つ追加されるかもしれません。

今回、僕は「現実的な REST の実践(仮)」というタイトルで、実際のところ REST はどうつかえるのか、という話をしようと思っています。Cool URI とか Uniform Interface などが実際にどう Cool で Uniform なのかを昨年よりは具体的にお話できればと思っています。

これが知りたい、という話があったらブログのコメントかブックマークコメント(del.icio.us とはてなブックマークとライブドアクリップは見てます)でご意見をいただければ、できるだけ応えられるようにしたいと思います。

先ほどの xml-users への村田さんの投稿によると数日前の段階で70名の参加者だそうなので、参加希望の方はお早めに申し込みください。

REST 本

2006-11-06T20:15:00.000+09:00

オライリーから REST の本が来年5月に出るらしい。

著者は Leonard Richardson と Sam Ruby。 Leonard Richardson さんは知らなかったけど、有名な人なんですね。

目次を見るとわかるけど、REST のアーキテクチャスタイルとその実装としての Web をリソース指向アーキテクチャの観点で ruby コード付きで語るというわくわくするような内容です。

日本語版欲しいなあ。誰か訳してくれないかなあ。

[update 2007-09-21] その後出版されました。

Webサービスプラットフォームアーキテクチャ

2006-09-21T22:59:00.000+09:00

という本が2月に出ていたらしい(結構分厚いので読むのに時間がかかる)。

Webサービスプラットフォームアーキテクチャ
Sanjiva Weerawarana Frank Leymann Donald F. Ferguson

原著の著者はみなさんは WS-* の著者欄に名前を連ねている方々(特にIBM)で、仕様策定のバックグラウンドを語らせたら右に出るものはいないと思われる。本書ではその著者達が WS-* の各仕様を設計思想から解説しているので仕様書を読むよりも楽にその背景思想を理解できる、と思う。

ちなみに REST もしっかりとアーキテクチャスタイルとして紹介されていて、その最大の特徴(Uniform Interface)と WS-* の interface 中心主義との違いが簡単に述べられていた。

さらに、実は本書はエンタープライズ環境の分散コンピューティングの技術の基本をざっと概観するのに適しているのではないかとも思う。目次を見てもらうとわかるけれど、メッセージングの基礎から、discovery, description, reliability, security 等一通りのことは書いてある。 WS-* からより抽象的な概念に変換する能力は必要だが、このあたりに興味のある方にはお勧めである。

WEB+DB PRESS Vol.34

2006-08-22T22:57:00.000+09:00

WEB+DB PRESS Vol.34 が届いたので読んでみました。

内容は naoya さんが書いてるとおり。かなりいいかんじ。

まず僕が気になった記事は Web 認証 API 特集でした。かなり基礎から最新動向までコンパクトにまとまった記事なので、 Web の認証まわりにそんなに詳しくない人に説明するのに丁度いいです。ただ例がはてな認証APIばっかなので :-)、もう少し他の例があると嬉しかったです。

次に、弾さんの DHH インタビューも面白かった。弾さんのインタビューの仕方がとても上手で、 DHH がいかにエンジニアとしてセンスいいかを引き出している感じでした。

あとは第一特集の性能改善かなあ。この辺も Web 上を頑張って探せば見つけられるんだろうけど、こういう風に紙媒体でまとまって読めると人に勧めやすいし、体系的に書いてあるので自分が知らなかった使い方を発見できます。

これだけ Web に情報が溢れている現在、紙媒体の従来メディアは存在意義を問われているわけですが、 WEB+DB PRESS さんは自身の立ち位置をちゃんと意識してすごく上手に企画をされていると思いました。

WEB+DB PRESS Vol.34: WEB+DB PRESS編集部; 技術評論社 2006-08-24

XML の本当のメリットは拡張性を保証して構造化文書もマークアップできること

2006-08-20T22:17:00.000+09:00

デジャビュを感じる。

XMLの「本当のメリット」ってなに？

Matzにっき XML のメリット、デメリット

XML の仕様には歴史的・政治的理由でいろいろと不満な点があります。これは XML をやればやるほど感じるものです。しかし、拡張性を保証して構造化文書もマークアップしようとすると選択肢は XML しかないのもまた事実です。

ということで、

構造のあるデータが書けること(すずきひろのぶさん)

別にS式でもYAMLでも書けますよね。拡張性のあるテキストのマークアップという意味(テキストが主、マークアップが従)ならSGMLの系譜を否定しませんが、データ記述や設定ファイルにまでとなると話は別です。

Matzにっき XML のメリット、デメリット(追記より)

結局はここに落ち着くのではないでしょうか。 XML というメタ言語の設計が構造化文書のマークアップに寄っているので、データ記述や設定ファイルに使うとどうしても冗長性が鼻についてしまいます。つまり用途によっては XML が最良の選択とはなりえないと僕も思います。 (参考: 檜山さんによる JSON と XML の比較)

あと「野良XML」のほとんどが名前空間を使っていない云々というのは単なる印象っぽいので、どのくらいの割合で使っていないのか不明なんですが、仮に名前空間を使っていない野良 XML であったとしても将来的には名前空間を使って拡張することが可能になることは忘れてはいけないと思います(例: RSS 2.0)。

Open Data が叫ばれる昨今、Web 上を流通するデータフォーマットではこの拡張性というのは非常に重要な概念なのでやっぱりX重要

The Atom Publishing Protocol as Universal Web Glue

2006-08-01T23:47:00.000+09:00

RSS and Atom in Action の人 Dave Johnson が TriXML 2006 で発表したスライド。74ページより

APP as universal web glue

Not just for blogs anymore

Entries can carry any type of data

You can do a lot with collections + CRUD

Consider Atom Publishing Protocol as the basis for your next web service

What's missing

Hierarchical collections

Collection queries

Beyound blogging: Understanding feeds and publishing protocols

フィードや APP はもはやブログだけのものではなく、 Atom の提供する entry と collection という汎用 XML と CRUD は Web 全体をつなぐ接着剤の役目を果たし始めていると。 APP を Web サービス基盤として捕らえるのがもう普通になってきた感じです。

ちなみに "The Atom Publishing Protocol as Universal Web Glue" というのは OSCON での Tim Bray のセッションのタイトルですね。

本3冊

2006-07-28T23:12:00.000+09:00

しばらく時間が空いてしまいましたが、最近気になった本を3冊紹介します。

まずは Flickr の中の人、Cal Henderson の Building Scalable Web Site。

REST が設計思想からスケーラビリティを攻めているのに対し、この本は実践からいかにスケーラブルなサイトを構築するかを攻めています。似たような話は古くは LiveJournal の中の人から、 Flickr の中の人まで、さらに最近は mixi の中の人やはてなブックマークの中の人 (ビデオ)、ライブドアの中の人までさまざまなテクニックや経験則を公開してくれていて、まさに高速道路建設中なわけですが、この本はその高速道路のひとつの出口になるんじゃないでしょうか。ぜひ日本語版もほしい一冊だと思います。

Building Scalable Web Sites
Callum Henderson Cal Henderson

2冊目はデータ工学の研究者なら誰でも知っている Data on the Web の翻訳、「XML データベース入門」です。

訳者の国島先生は僕も知り合いですが、日本でまじめに XML 関連の研究をなさっている研究者のお一人です。国島先生の翻訳解説エントリにもあるとおり、かなり丁寧に翻訳さている印象です。特に XML の解説の章の訳注の入れ方は半端じゃないです。

本書で扱われているトピックは半構造データ(semi-structured data)、特に XML のデータモデルとその問合せ処理についてです。いわゆる学術書なので、自分には関係ないと思う人も多いかもしれないですが、現在一般に扱われているデータ RSS, Atom, JSON なんてのはまさに半構造データなわけです。そういったデータをいかに蓄積し、検索するか。そんな問題を考えている人は手にとってみるとよいかもしれません。

ただ、一点だけ気になったのは、キーワードが日本語オンリーなところ。英語も併記してもらえると、特に初学者には理解が進むと思いました。もし訳語リストがあれば、公開していただけませんか＞国島先生。 2006-08-01 追記: コメント欄で索引に訳語リストがあることを教えてもらいました。

XMLデータベース入門
Serge Abiteboul Dan Suciu Peter Buneman

最後は翔泳社の Web 2.0 キーワードブックです。これは僕もお手伝いをしました。REST の章を書いてます。たぶん、これまで書いた REST の解説の中で一番コンパクトにまとめたものになっています。あまり Web 技術に詳しくない人にも理解できるように、なるべく平易な記述を心がけたつもりです。

Web 2.0 という言葉はすでに陳腐化してしまった感がありますが、ギークのそういった気分もいくらか取り込まれていて、特に切込隊長のエピローグには思わずニヤッとしました。

それにしても、献本をもらうまで著者陣を知らなかったのですが、かなり強力ですね。個人的には自分の原稿がまつもとさんと村田さんの間だったのに感動しました。

Web2.0 キーワードブック
SE 編集部

次の話

2006-05-10T01:15:00.000+09:00

blogger が落ちてたんで遅くなりました。

http://subtech.g.hatena.ne.jp/miyagawa/20060509/1147161767

http://naoya.g.hatena.ne.jp/naoya/20060509/1147157679

この Hack が素晴らしい。で、見てておもったんだけど、ウェブのフロントエンドアプリケーション作りが得意な人は、そのフロントエンドアプリケーションから利用するバックエンドの API を規定して、API のエンドポイントを任意の URL に設定できるとかそういうものを作ったりとか、そういう時代が来る。

大体近いんだけど、ちょっとまとめ方が違ってる。

(中略)

Amazon Web Services みたいな、「APIでデータとれるのでどうぞあなたのアプリでつかってください」っていうのが旧時代の Web API で、Amazon の場合はこれでも結局最後は集客につながるからいいんだけど、次の Web API ってのは逆で、「APIにあわせてアプリかけば、こっちのサービスで使えるようにしてあげますよ」ってやつ。こっちのほうがより「つながってる」感じがする。

このやり取りがこれだけの短時間のうちに行われているのがさすが miyagawa さんと naoya さんという感じ。僕はこういう見方で Livedoor Reader を見ていなかったので、かなり感銘を受けた。以下はそこから出た妄想です。

思うにこれからの Web サービスは三つに分離するのではないか。ひとつは Amazon S3 や Google Base や Flickr やはてなブックマークのようなデータストア提供サービス。二つ目は OpenID/Typekey 認証やはてブの件数取得 API や SimpleAPI のような機能提供サービス。そして三つ目が今回の LDR のような UI 提供サービス。

データストア提供サービスというのはわかりやすいと思う。これまではローカルに保存されていたようなユーザデータを Web 上にもってきて付加価値をつけて提供するサービスのこと。

これに対して機能提供サービスは基本的にデータは保持しない。もちろん設定情報とか最低限は持つんだろうけど、あくまでもそれだけ。ユーザの一番大切なデータの保管は他にまかせちゃう。そのかわりにそこでしか提供できない機能を提供する。

んで UI 提供サービスを使ってそれらをマッシュアップするわけです。

こうなってくると、データストア提供サービスや機能提供サービスは、固有の UI を持つかもしれないけどそれはあくまでもオマケで、彼らの本当の価値はユーザデータの格納と各種機能の提供になる。そして UI サービスは、いかに汎用的かつ拡張可能な機能を持ち、かつ洗練されたユーザインターフェースを作るか、が勝負になる。 LDR は今まさにこの先頭を走っていて、そこにこそ価値があるのかも。

つまりはてブの編集フロントエンドに LDR がなったらすごくね、ということですね。今はまだ完全にはできないけど。もっと言うと誰でも最速の人が作る UI を自分のサービスのフロントエンドエンジンとして使えるようになるということです。

あとは各サービス間のインターフェースが問題になるんだけど、データストアの大本命は Atom Store (APP)でしょうね。各データストアサービスは GData のように必要な拡張タグを施して Atom フィード/エントリを提供する。 UI や機能提供サービス側は共通タグにはもちろん対応するんだけど、それ以外の拡張タグや microformats にも対応していく。拡張タグに対応する UI 機能を pluggable に作る必要もありそうだ。

もちろん課題はかなりある。たとえば現状では Greasemonkey がないとだめ。しかもたぶん GM_xmlhttpRequest 使って別ドメインにアクセスすることになるんで、セキュリティの問題がつきまとう。これは cross-domain 対応の XMLHttpRequest の実装が揃うまで待つしかないのかな。よく知らんけど

それから認証と SSO も。そこをうまくやらないと使ってもらえないし。

あと一番難しくてだからこそ希少価値があるのは LDR レベルの UI が作れるエンジニア(というかデザイナかな)かもしれない。流れはそっちだと思うんで、がんがれ若者

日経SYSTEMS。

2006-04-25T22:36:00.000+09:00

日経SYSTEMS 5月号で Web 2.0 関連技術(特にREST)がシステム開発に与える影響についての取材を受けました。 P60に数行だけ僕の発言が引用されていました(下記に引用したので全文)。僕がしゃべったこととはちょっと違ったのでここで訂正しておきます。

コンテンツを読むだけでなく、簡単に書き込めることが重要。

これはそのとおり。

REST では GET に PUT と DELETE を加えれば Web ブラウザだけでそれが簡単に実現できる。

これは言ってないよー。ブラウザだけで簡単に実現はできないっしょ。少くとも現時点では。

新たに SOAP を覚える必用がない

まあそうかもしれない。ただ、これに相当することを言った覚えはないんですが…。

WEB+DB PRESS Vol.32 に REST の記事を書きました

2006-04-20T22:03:00.000+09:00

naoya さんが先に言及してくれてますが、WEB+DB PRESS Vol.32 に「REST アーキテクチャスタイル入門」という記事を書きました

Web アプリケーション開発者の方を対象に Web アプリでの REST から Atom Publishing Protocol まで、かなり細かく解説したつもりです。はてな技術発表会で naoya さんが XML 開発者の日の参加報告をしているのを聴いて、普通の Web アプリケーション開発者の人にももっと REST を知ってもらえたらいいなと感じたのがその理由です。なのではてなスタッフの方々にはぜひ一人一冊ずつ購入していただければと:-)。

ただ、やっぱり REST は難しいですね。人に説明するたびに思います。記事でわからないことがあれば、ここにコメントしていただければできる範囲で返答しようと思います。

WEB+DB PRESS Vol.32: WEB+DB PRESS編集部; 技術評論社 2006-04-25

しかしこの号、結構面白いですね。 miyagawa さんの連載は参考になるし、その隣の弾さんの連載にはお茶目な Larry Wall が登場しています。あとは naoya さんの新連載は Catalyst の話だし、gorou さんの新連載は prototype.js の解説と、かなりツボを抑えている感じです。

Shibuya.js 行ってきた ($X 最高)

2006-04-15T09:22:00.000+09:00

昨日デジハリで行われた Shibuya.js Technical Talk#1 に行ってきました。 id:secondlife さんの結成宣言に始まり、えとさんによるこの10年と次の10年の話、 IT戦記 amachang さんが javascript を300倍高速化した後、竹迫さんによる爆笑プレゼン、 mala さんが自身の開発環境+ポリシーを余すことなく公開し、 id:secondlife さんから RJS Template のソース嫁とありがたいお言葉を頂戴して、怒涛のライトニングトークの最後は怖いビデオをマッタリと視聴しつつ、 id:thx さんの軽快な司会て幕を閉じました。

どの発表も大変面白かったのですが個人的には cho45(さとう)さんの $X リスペクトです。僕もグリモンスクリプトをちょこちょこ書いて遊んでいるんですが、ちょっと前に見つけたこの $X なしではもう書けません。 DOM level 3 の XPath 拡張は非常に低レベルで、単に XPath でノード指定したいだけなのになんでこんな長ったらしいコードを書かなければいけないのだと思うわけですが、この $X 使うと1行で書けます。さらに $X のインターフェースがまたよく考えられていて、 XPath の評価結果のノードタイプに応じてきちんと返る値が動的に変わったり、 context 省略できたり、コードを書いていてストレスがまったくありません(名前空間出てくるとちょっとストレスたまるけど…)。これと XPath 検索バー組み合わせて開発してると、いわゆる「俺ってばスゲー」的爽快感を味わえます。

グリモン使いには超おすすめ。

カミングアウト。

2006-03-21T16:40:00.000+09:00

Tim Bray の WS-Crossroads から REST 関連のブログエントリが凄いことになってます。 Tim のエントリはガートナーの group VP で chief fellow な Daryl Plummer の Web Services At A Crossroads という記事を受けてのもの。 Plummer の文章はツッコミどころがあるものの、いいこといっているのも事実だと。

Tim のエントリは最後の段落がとてもいいです。

Speaking for myself, not for Sun, I think that we ought to be pouring resources and investment into tooling and developer support around simple XML/HTTP/REST technologies. You know, the standardized ones that work today.

これを受けたのがマイクロソフトの Don Box です。まず Going Down To The Crossroads... というエントリで、 Tim の上記の段落を受けて、マイクロソフトの環境・ツールがどれくらい HTTP/XML/REST をサポートしているかをまとめてくれています。

さらに Don の次のエントリでは HTTP, XML, REST, and $100 と題して、もし $100 あったら、HTTP/XML/REST 関係の開発の何にどれくらいを費やしてほしいか、の意見を求めています。このコメントやトラックバックが面白いんですが、Dare Obasanjo の反応がまじめにいいです。いわく $40 を IE での XML サポート強化(E4Xとか)に、$30 を WCF での RESTful サービスサポートに、 $20 が C# と VB.NET での XLinq サポート、最後の $10 は W3C じゃない XML 技術(RELAX NG や Schematron)のサポートと。

その後はlesscord での勝利宣言(いくつか心配もありますが)があったり、 Mix06 でビルゲイツが "We need microformats" と言ったり、時代が確実に動いているという感じですね。

最後に僕もいちおうカミングアウトしておこうかな。

I'm a Restafarian.

REST ってやっぱり難しいかも。

2006-03-04T00:42:00.000+09:00

前のエントリでこんなことを書いたばかりだけれど、REST ってやっぱりどうよ、という気分になったので久々に blog を更新してみる。

ただただしさんのおれだったらフォト蔵APIをこうするを読んで、僕が del.icio.us に書いた感想は

+1。ID == URI ですよね。Cool URI は名詞であるべき、というのは強調したい。「日本REST協会」入りたくないなー(笑)。みんな休んでそう

というもの。たださんのエントリでは URI と書くべきところが ID になっててちょっと気になったり、「作法」は「アーキテクチャ」じゃなくて「アーキテクチャスタイル」だ、とか思ったのだけれど、でも本筋としては納得の内容だった。

しかし、たださんのエントリの、たかはしさんや mizzy さんのコメントを読んでうーんと唸ってしまった。

僕にはお二人の言いたいことがわかる。んで両方間違っていないと思う。

たとえばたかはしさんの言うとおり、RoyF の元論文では GET/POST/PUT/DELETE を使えなんて一言も書いてないわけで。そうじゃなくて単に Uniform Interface が重要だよ、というだけの話。

でも今回のフォト蔵 API に関して言えば、Uniform Interface の間違った使い方をしちゃっているので、ちゃんと RESTful に設計するなら HTTP の GET/POST/PUT/DELETE をたださんが指摘したように使うのがまっとうな方法だとも思う。

mizzy さんのコメントの最後

ここでたださんが言っているRESTというのは、正確には「RESTアーキテクチャスタイルのアーキテクチャであるHTTPを利用したAPI」のことだと思われますので、アーキテクチャの話に絞って問題ないかと思います。

というのは重要で、問題の根源はここにある気がする。異なる次元の別の話(アーキテクチャスタイルの話、HTTP の話、Web API 設計の話)が全部 REST という名前の下で行われていうので、混乱してしまう。これは僕にも一因があって、これまでのこの blog のエントリでも上記をごっちゃで使ってしまっている。

言葉を正確に使おうとすると非常にメンドウなので、僕自身の文章力ではなんともならないのだけれど、ここではせめてそれぞれの次元がどう違うのかを下記に列挙しておきたい。

REST アーキテクチャスタイル: RoyF の元論文に基くアーキテクチャスタイルについての議論。ここでは HTTP のメソッドがどうしたという話は原則関係ない。 REST アーキテクチャスタイルを基にした Web アプリのアーキテクチャを設計する段で、たとえば GET/POST/PUT/DELETE を使うのがいいのか、 GET と POST だけを使えばいいのか、という議論もありえる。このレベルの話を、下記の偶然 REST っぽい Web API に適用してもあまり意味がない。プログラミング初心者にいきなり最先端のデザインパターンの話を聞かせるようなもの。
偶然 REST っぽい Web API: いわゆる XML を HTTP でやりとりしますよ的な API を REST API と呼んでいるケース。この場合の REST という言葉は非常に矮小化されてしまっていて、僕としてはこれは POX over HTTP と呼びたい。個人的には正直あんまり興味なし。
Restful Web サービス: RoyF の論文はそこらの××な(自己規制)博士論文の1万倍凄いんだが、それでもやっぱり脇が甘いところもあるし古くなっちゃってるところもある。それに REST アーキテクチャスタイルを実装(アーキテクチャ)に落そうとするととたんに色々な問題が出てきて、そう単純な話では済まないのも事実。一方で2000年以降、このような設計・実装の議論はずっとされてきて、進化してる。実際にいろいろな試みがなされていて、Paul Prescod の経験則とか Mark Baker の蘊蓄とか、すごく蓄積されている。たとえば POST は新規作成とか URI は名詞でとかいう話はより実装に近い話。 APP(AtomPP) はここでの重要な成果の一つ。; その他にも REST にまつわる現在進行形の議論はたくさんあって、たとえば OOP と REST とか SOA/WS-* と REST とか Ajax と REST とか XML vs YAML vs JSON とか階層化ファイルシステムと単一階層モデルとか microformats と REST とか。まさに Web 2.0 が表現するアルファギークの気分の中でフワフワ浮いているような話題なんだけれど、この話題、まだ体系的に言語化/文書化されてないので現在進行形の文脈を共有している人とじゃないと議論できない。僕が今一番興味があるのはここ。

実は今 REST の入門記事を某誌向けに書いているんだけど、この原稿でも上記の次元の異る REST が無意識にまざってしまっていて、困ったなあと思っていたりする。締切も近いしどうするかなあ。

REST は難しい、だからこそ面白い

2006-01-31T22:01:00.000+09:00

知り合いに教えてもらって知ったのだが、今月の日経ソフトウエアは Web プログラミングの特集である。ちょっと立ち読みしたところ、内容は Web 2.0 まわりの記事だった。その特集の中の囲み記事で REST と僕の名前が出てくるところがある。「わかりづらい REST という言葉」というタイトルで、 REST がアーキテクチャスタイルであること、一方で REST API は「ホームページ」のような誤用であるが、そちらの方が一般的になってしまっていること、が簡単に記述されていた。

REST == HTTP GET+XML のような紹介よりも1万倍よかったし、何よりこういう初心者向けのメジャー(?)な雑誌記事で REST に言及するようになって、本当によかったと思う。1年前には考えられなかったことだ。

ただ、気になったのは REST が難しくてわかりづらい、という話だ。

そりゃ確かに REST は難しい。RoyF の論文を読みこなすには相当知識が必用だし、僕の REST 入門もやっぱり難しいと思います。コンテキストを共有していないと。僕自身、SOAP で Web サービスを一通りやって、その長所短所がわかってからやっと、REST の良さを認識できた。

でも一方で本当に難しいのかな、とも思う。いや、なんというか、「難しさの質」の問題とでもいうか。たとえば XML Schema の複雑怪奇でどこから手をつけていいのかわからないような難しさ、あるいは BK 的な奥が深い難しさ、とは性格が違うんじゃないだろうか。

そしてさらに思うのは、そういう難しさの質が違うものに対して、単に難しくてわかりづらいから、楽でわかりやすい方に流れるというのは技術者としてどうなんだろう、ということ。難しくてもシンプルだったり、美しかったり、論理的に納得させてくれたりするものの方が、複雑なものを上辺だけ楽そうに見えるカワを被せて隠蔽しているものよりもずっと本質的で面白いのではないだろうか。

REST は難しい。でも、ただそれだけの理由で REST がバズワード化して誤解されてしまうのはなんだか悲しい。

Atom で件数取得

2005-12-12T23:35:00.000+09:00

なんか催促されちゃったみたいなので :-) 詳しく書いてみます。

はてなのブックマーク件数取得 API いいですね。今さら xml-rpc かよ! というツッコミは置いておいて、データ重要な世の中で有用なコンテンツ(メタデータ)にリーチする方法が増えるのは喜ばしいことです。

そうそう、こういう API を AtomPP で実装するとしたらどんな感じなんだろう。そもそもうまくフィードで定義できるのか。教えて偉い人!

偉い人じゃないけど、結論からいえば、 Atom Publishing Protocol (APP) そのままじゃ無理です。やってもいいけどどうしても無理が出てしまいそう。そもそも目的が違うのだから、ここは野良 XML/プロトコルでいいのでは。ただ、結果をフィードで取れるとそれなりに嬉しいかもしれない。

普通 REST で検索するときは query string を使った URI を GET することになる(検索結果リソースを GET する)んですが、今回の場合のようにパラメータがたくさんあったり長かったりする場合は GET は現実的ではありません。こういうときは問合せ文書(query document)を POST で投げます。

POST /atom/exist HTTP/1.1
Host: b.hatena.ne.jp
Content-Type: application/xml
Content-Length: xxx

<uri-list xmlns="http://ns.hatena.ne.jp/uri-list">
  <uri>http://d.hatena.ne.jp/naoya/20051212</uri>
  <uri>http://yohei-y.blogspot.com</uri>
</uri-list>

結果はたとえば XML 形式で取れます。

HTTP/1.1 201 Credated
Host: b.hatena.ne.jp
Content-Type: application/xml
Content-Length: xxx
Location: http://b.hatena.ne.jp/atom/exist/1234567890abcdefg

<bookmark-list xmlns="http://ns.hatena.ne.jp/bookmark">
  <bookmark>
    <uri>http://d.hatena.ne.jp/naoya/20051212</uri>
    <count>5</count>
  </bookmark>
  <bookmark>
    <uri>http://yohei-y.blogspot.com</uri>
    <count>4</count>
  </bookmark>
</bookmark-list>

ここでのキモは Location ヘッダで検索結果リソースの URI を返しているところ。この URI を GET すればいつでもこの検索結果(の最新版)が取得できると。

リクエストとレスポンスは野良 XML でもいいんですが、これくらいの情報なら JSON の方がプログラムから扱いやすくて便利ですよね。実際、グリモンとかから使うなら JSON の方がいいと僕も思います。

ただ、レスポンスの場合、野良 XML じゃなくて Atom フィードだといいことありそうです。

HTTP/1.1 201 Created
Host: b.hatena.ne.jp
Content-Type: application/atom+xml
Content-Length: xxx
Location: http://b.hatena.ne.jp/atom/exist/1234567890abcdefg

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>はてなブックマーク検索結果</title> 
  <link rel="self" type="application/atom+xml"
    href="http://b.hatena.ne.jp/atom/exist/1234567890abcdefg"/>
  <updated>2003-12-13T18:30:02Z</updated>
  <author><name>Hatena</name></author> 
  <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>

  <entry>
    <title>なおやのはてなダイアリー</title>
    <link href="http://d.hatena.ne.jp/naoya/20051212"/>
    <link rel="alternate" href="http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/naoya/20051212"/>
    <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
    <updated>2005-12-13T18:30:02Z</updated>
    <summary>5</summary>
    <content type="xhtml">
      <!-- リンク、キーワード、タグなんかをそのまま入れる -->
    </content>
  </entry>

  <entry>
    <title>yohei-y:weblog</title>
    <link href="http://yohei-y.blogspot.com"/>
    <link rel="alternate" href="http://b.hatena.ne.jp/entry/http://yohei-y.blogspot.com"/>
    <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
    <updated>2005-12-10T10:34:02Z</updated>
    <summary>4</summary>
    <content type="xhtml">
      <!-- リンク、キーワード、タグなんかをそのまま入れる -->
    </content>
  </entry>

</feed>

ブックマーク件数は summary に入れるの? とか(summary/content の中で microformats 的にやったほうがいいかもしれない)、いろいろツッコミどころはありますが、雰囲気は伝わるんじゃないでしょうか。

イメージとしては、現在の人間用はてなブックマーク一覧のページで、表示するブックマークを一つ一つ指定できるようにした感じです。今のブックマーク一覧ページで取れている情報をそのまま Atom フィードにしたものを想像してもらえればいいでしょう。カテゴリなど、Atom で用意されている要素はそのまま使ってもよさそうだし、足りない要素・属性があればはてなの名前空間で足せばいいだけ。

Atom フィードなんで、RSS リーダで購読すれば更新情報も取れます。自分の気になる記事がどれくらいブックマークされてるかどうか気になる人にはけっこう嬉しいんじゃないでしょうか。

まー、フィードは Atom じゃなくて RSS でもいいじゃん、といわれちゃいそうだけど、RESTful に考えるとこんな風になるという参考までに。

追記: 例のレスポンスのステータスコードを 201 にしました。

山田さんの資料

2005-11-27T13:21:00.000+09:00

XML 開発者の日の tai さんの資料をいただいたので公開します。 REST, Atom, and WebDAV

Paul Prescod の Common REST Mistakes

2005-11-26T22:53:00.000+09:00

Paul Prescod の Common REST Mistakes の翻訳版を公開しました。

本当は今年の1月に訳してたんですが、諸般の事情で公開するまでに時間かかってしまいました。また、村田さんからたくさん助言をもらって訳文を修正してあるんですが、それでも Paul の文章は僕には難しくてあんまり読みやすい日本語にはなってません。ただ非常に含蓄のある内容ですのでぜひ原文とあわせてご覧ください。

第八回XML開発者の日

2005-11-25T21:04:00.000+09:00

昨日、第八回XML開発者の日が開催されました。死ぬほどつかれたけれど、死ぬほど面白かった。こんなにまじめに一日中頭を使って人の話を聞いたのは久しぶりです。

僕の発表資料とパネルのときに即席で作ったスライドです。発表資料の方はもんたメソッドなのでスライドショーで見てください。パワーポイントない人は OOo でお願いします。(2006-04-11 置き場所修正)

以下、感想とまとめです。

REST入門山本陽平(株式会社リコー): REST の入門編を喋ってみました。なるべく基本的なところを丁寧に話したかったんですが、成功したかどうか… コネクタの話をしなかったので、高橋さんにちょっとご迷惑をおかけしました m(_ _)m
はてなとREST API 伊藤直也(株式会社はてな): モテ重要、ということでなんではてなが APP を採用したのか、その根底に流れるデータ重要という考え方、サーバサイド実装における Cool URI の重要性、などがわかりやすくまとまっていてとても参考になりました。
RESTful Wiki の実装 gorouこと舘野祐一(株式会社ディノ): REST のことがわからんから作ってみたという gorou さん。わからないといっている割に実装はとても素直に REST をなぞっていて、やはりアルファギークがよいフレームワークできれいに実装すると REST の流儀に従ったアーキテクチャになるのかな、と思った次第です。
API としてみた Movable Type と TrackBack 平田大治(シックス・アパート株式会社): みなさんが感想で書かれているように、トラックバックが海外ではあまり普及していない、というのは意外な事実でしたね。実際この blogger も SixApart の LiveJournal もデフォルトではトラックバックできません。平田さんの発表のキーワードはプラットフォーム重要、でしょうか。
WebDAV/REST/AtomAPI 山田泰資(株式会社インターネットイニシアティブ): tai さんのお話は僕の期待以上でした。歴史を詳しく捉えつつ REST/Atom と WebDAV を比較。そして実装の問題へ。僕が聞いた範囲でも tai さんの発表が一番面白かったという人が多かったです。
Ajax が REST に及ぼす影響高橋征義(株式会社ツインスパーク): REST 萌えな高橋さん。僕も「REST は割と好き」です。高橋さんから出てきたキーワード "conector on demand" は Ajax 時代の REST を端的に表現する言葉じゃないかと思います。それにしても生高橋メソッドはすごかった。
The Service-Oriented Mark Baker(株式会社ジャストシステム) 発表代理: 村田真: 村田さんいわく Mark は日本のレベルをなめていた、ということでさらっと発表が終わってしまいましたが、 Mark のスライドは参考になります。特に OPTIONS を例で出してくるところなんかさすがというか、他の誰も触れなかったところなのでよかったです。
パネルディスカッション: パネルの直前に村田さんに仕事の電話がかかってきていきなり会場で仕事をしだすというハプニングが (^^; ちょっと心の準備ができていなかったのでとてもあせりました。ということで僕が進行役をやったせいであんまりまとまりのない流れになってしまってごめんなさい。会場からみなさんどんな言語やフレームワークを使っていますか? という質問をいただいたら盛り上がりましたね。なんというかほんとに皆さんいい意味でばらばら。そして Ruby と Rails の強さが改めて印象に残りました。

あと、会場で eto さんにはじめて会えたのが1995年から Web やってる人間としてよかった点です。

詳細な議事録を入手したのではてなブックマークに載せておきました。Tさんありがとう!

Windows Vista の RSS パーサは Well-formed XML のみサポート

2005-11-07T23:36:00.000+09:00

Dare Obasanjo の blog で知ったんですが、 Microsoft Team RSS Blog より

Our years of experience in with HTML in Internet Explorer have taught us the long-term pain that results from being too liberal with what you accept from others. Hence, we’ve adopted the following overriding principle for IE 7 and RSS platform in Windows Vista:

We will only support feeds that are well-formed XML.

This principle allows us to build a more predictable feed parser. As a platform, it's important that applications using the platform to consume feeds can rely on the fact that the platform will always be providing information in the way that the publisher intended (trying to guess what a publisher meant to do when there is an error in a feed can be tricky, at best). We also spoke to several people in the RSS and developer community at Gnomedex and at PDC, and they wholeheartedly supported this.

IE7 と Windows Vista の RSS パーサは整形式(well-formed)の XML だけをサポートすると。現在世の中で流通している RSS フィードがどれくらい well-formed なのか知らないのですが、英断だと思います。

XML 開発者の日、見どころ聞きどころ

2005-10-18T23:40:00.000+09:00

村田さんからアナウンスがあったとおり11月24日(木)に新富町の印刷会館で XML 開発者の日が復活します。

5月の WWW2005 で村田さんにお会いしたときに、開発者の日で REST を扱いたいですよね、という話をしていたのですが、画像電子学会という事務局がみつかって開催のはこびとなりました。 REST について議論する場がずっと欲しかったので、今回は僕も準備のお手伝いをさせてもらいました。具体的には何人かの発表者の選定や連絡などさせてもらってます。

さて、プログラム(予定)ですが、現時点で REST の話を日本語でするならほぼベストな布陣になっていると我ながら思います。以下では僕の独断と偏見で、各講演の見どころ聞きどころを説明したいと思います。

REST入門山本陽平(株式会社リコー): 朝イチで僕が REST の入門編を喋ります。ベースはこの blog の REST 入門ですが、これはかなり uniform interface に特化した内容になっているので、それ以外の REST の特徴についてもできるだけ丁寧に触れられるようにしたいと思います。 REST って? という人はまずここで予習をしてください。ちなみに開発者の日で話すのは5年ぶり。
はてなとREST API 伊藤直也(株式会社はてな): 続いていきなり naoya さんが登場。知っている人は知っていると思いますが、 naoya さんの講演は blog と同じで大変わかりやすいです。今回はかなり技術的につっこんだ発表が聞けるのではないかと思います。とくにサーバ側の実装が気になる人は必見でしょう。
RESTful Wiki の実装 gorouこと舘野祐一(株式会社ディノ): 発表者リストを考えながら、誰にお願いしようかなーと悩んでいたところで、gorou さんの RESTWiki が巷で話題になりました。 XMLHttpRequest を使ってブラウザを REST クライアントにするというアイデアは以前からみかけたのですが、それを実際に実装しているところ(しかも rails で)に感動しました。 rest+rails の話が聞けるのは幸せです。
API としてみた Movable Type と TrackBack 平田大治(シックス・アパート株式会社): 平田さんは説明不要ですね。日本における blog の教祖みたいな人です。 AtomPP よりも前から trackback api は RESTful でした。 TrackBack の本家本元 MT で REST がどう扱われていくのか、そんな話が聞けるといいですね。
WebDAV/REST/AtomAPI 山田泰資(株式会社インターネットイニシアティブ): 山田さんは知る人ぞ知る日本の RESTafarian です。 REST がこんなに盛り上がるはるか前から、 REST に関する論考を発表されていました(リンク切れなのでアーカイブをどうぞ)。僕も山田さんの Wiki ではかなり勉強させてもらっていて、個人的には今回一番楽しみな発表です。
未定高橋征義: みなさんご存知、高橋さんです。高橋さんは第1回 XML 開発者の日でも発表されています。高橋さんといえば Ruby, Rails (そして高橋メソッド)ですが、 WWW のアーキテクチャスタイルとしての REST にも早期から着目されています。高橋さんならではのわかりやすいプレゼンで、 REST アーキテクチャスタイルを語ってもらうのが楽しみです。
分散オブジェクトから REST へ(仮) Mark Baker(株式会社ジャストシステム) 発表代理: 村田真: Mark Baker は Roy Fielding、Paul Prescod に並ぶ REST 推進者の一人です。彼自身は独立コンサルタントですが、現在の彼のクライアントにジャストシステムがいるそうで、日本との関わりも多いようです。今回は Mark と知り合いの村田さんが、直接 Mark に発表スライドの作成を依頼してくれました。 Mark の blog や経歴を読んでもらえればわかりますが、彼の分散オブジェクトから REST までの経験と知識は世界一です。彼の発表が日本語で、しかも村田さんの代理発表で、聞ける機会は本当に貴重です。
パネルディスカッション発表者 + 丸本徹(有限会社ウィザシステム) + 大野邦夫(株式会社ジャストシステム) + 大谷真(湘南工科大学): パネルの内容はまだ未定ですが、パネリストは豪華ですね。丸本さんは BlogWrite の開発者で、 Atom にとてもお詳しい方です。丸本さんと発表者、さらに大野さんと大谷さんという重鎮を迎えて深い議論ができるのではないかと期待しています。

以上、簡単にですがプログラムを紹介してみました。ぜひ皆さんご参加ください。

Javascript+HTML のデザインパターン

2005-09-17T18:23:00.000+09:00

僕もご多分に漏れず Javascript で遊んだり調べたりしています。いろいろなクールなサイトの生 Javascript を見て勉強しているのですが、まず面白いなと思ったのがロールオーバーの実現方法です(JavaScript や HTML をわかってる人には当たり前の内容だと思うので、ツマラナイ話だと思いますが)。

WaSP の左上の画像のロールオーバーは

<img id="logo" src="/img/logo.gif" height="100" width="103"
  alt="Web Standards Project logo" />

生 HTML はこんなかんじで onmouseover/onmouseout 属性を記述せず、 JavaScript で

function initRollOvers() {
 var logo;
 if (document.getElementById) {
  logo = document.getElementById('logo');
 } else {
  return false;
 }
 /*if (document.all) {*/
  logo.onmouseover = swapI;
  logo.onmouseout = swapI;
 /*} else {
  logo.addEventListener('mouseover',swapI,false);
  logo.addEventListener('mouseout',swapI,false);
 }*/
  return true;
}

function swapI(e) {
 e = (e) ? e : event;
 thisI = (e.srcElement) ? e.srcElement : e.target;
 if((thisI.status != 'a') &&
    (thisI.status != 'p')) {
  thisI.src = '/img/' + thisI.id + '_a.gif';
  thisI.status='a';
 } else if(thisI.status != 'p') {
  thisI.src='/img/'+thisI.id+'.gif';
  thisI.status='';
 }
}

こんな風にして id 属性に logo という画像を持つ img 要素の onmouseover と onmouseout をページ表示時に動的に変更することで実現していました。

似たような手法は Nikon のサイトや Yamaha のサイトでも利用されています(両方同じ業者さんみたい)。

もう一つ、今度は別のところで、これと似た手法を見ました。

del.icio.us では delete リンクをクリックしたときにちょっとした工夫をしているのですが、このちょっとした工夫は下記のように実現されています。

delete リンクの HTML ソースはこんなかんじ。

<a href="/yohei?delete=9d7b7c953b1e47a7d82e791848f43899"
  class="rm" rel="nofollow">delete</a>

onclick 属性がなく Javascript の影も形もありません。

どうなっているかというと、ヘッダでロードしている Javascript で

function rmPostAddEvent() {
  var all = getElementsByClass(document.getElementById('posts'),'rm','a')
  for(var i = 0, o; o = all[i]; i++) o.onclick = function(){ return rmPost(this) }
}
function rmPost(o) {
  o.style.display = 'none'
  var s = document.createElement('span'); s.o = o
  s.innerHTML = '<span class="important">delete this post?</span> <a href="'+o.href+'">yes</a> / <a 

href="'+o.href.replace(/(\?|&)delete=[^&]*&?/,'$1')+'" 

onclick="this.parentNode.o.style.display=\'inline\';this.parentNode.parentNode.removeChild(this.parentNode);return 

false">no</a>'
  o.parentNode.insertBefore(s, o)
  return false
}

とやって、yes/no を追加しています。

ロールオーバーの例と del.icio.us の例で共通するのは、静的なコンテンツ部分(HTML)と動的な UI の振る舞い制御部分(JavaScript)を完全に別ファイルに分けているところです。もちろんこうするためには class 属性や id 属性の値にコンベンションが必要となるのですが、このようにアクションとコンテンツを分離することで、以下のようなメリットがありそうです。

コンテンツ生成プログラムの効率化: onmouseover などイベント系の属性を記述しないですむので、HTML 生成プログラムが効率化しそうです
メンテナンス性の向上: 上の項目につながりますが、問題があるのがデータなのか、スクリプトなのかの区別がつきやすそうです
HTML サイズの縮小: 要素毎に属性を記述しないですむので、ネットワーク転送量が減少します

さらに、class や id の値のコンベンションという意味で、microformats との相性もよさそうです。

さらに面白いと思ったのは、この動的・静的がサーバから見たときと、クライアントから見たときにちょうど対称的になっているところです。サーバから見ると、生成するデータ(ブックマーク一覧)こそが動的であり、そこに yes/no リンクという振る舞いを与える JavaScript プログラムは静的です(del.icio.us の URL にも static とある)。逆にクライアント(ブラウザ)から見ると、 HTML に入っているブックマーク一覧というデータは静的ですが、 JavaScript によってそれらを動的に変更しています。

こういうのってかなり抽象化できていて、正にデザインパターンと呼べそうな気がするのですが、何か名前があるんでしょうか(NDO メソッド)。ちょっと探してみたけれど、見つけられませんでした。勝手に behavior injection(振る舞いの注入) とか action injection (アクションの注入) と想像して検索してみたのだけれど。

microformats などの設計についていろいろ

2005-08-21T16:55:00.000+09:00

僕が提案した方法についておのひろきさんからツッコミが入り、 microformats を誤解している、マークアップする力の問題である、と批判されました。

まー実際、microformats を誤解しててマークアップする力もないかもしれないんだけど、おのひろきさんの主張には賛成できないので、ここでまとめて反論しときます。

まず、「microformats についての誤解と，ぼくが理解している範囲」より。前半の microformats の説明は特に異論はありません。でもそれがなんでいきなり

それでさらに microformats であるなら，一度「意味付けと記述書式」を決めたら，それが他での使い回す事ができないと意味がありません．限定された問題を解ければ良いとはいっても，特定の問題にしか対応できないほど限定してたら駄目なのです．

ってなっちゃんでしょう?(強調筆者) ここがまずわからない点。

rel 属性値は profile で定義してそこで意味付けをします．上の例では a 要素で rel 属性値 hatenab とある場合は href が指す URI ははてなブックマークであるってことになるのかな?

元記事では、主題が別だったので詳細なプロファイルまで書いてませんが、リンク形式 rel="hatenab" は、リンク先が元ページの著者のはてなブックマークへのリンク、という意味です。目的は「自分が使っているサービスを宣言」するため。

profile を定義するということを意識していないから rel 属性値をどうするかというところで間違えるのではないでしょうか．profile を定義することと，その profile が他で応用できるようにするということを考えないとダメだと思うのです．

最後のここもいまだにわからないんですよね。 rel を拡張するなら profile (microformats なら XMDP) が必用、というのはわかってるつもりです。でもそれと、「他で応用できる」ってどう関係があるんでしょうか? たとえば XFN は友人関係を記述する以外にどう「他で応用できる」んでしょうか?

続けて「マークアップする力」より。

檜山さんの記事を引用して

「邪悪マークアップは先進的マークアップか？」から引用すると:
これがまずい理由は、<田中>元気で行ってこい。</田中>や<ミヨ子>おみやげ、忘れないでねぇ</ミヨ子>のあいだに共通性があるのに、その共通性がマークアップにより表現されてないことです。
これと同じ事が rel="hatenab" と rel="delicious" にも言えると思うのです．

と書いていますが、同じとは言えないと思いますよ。

おのひろきさんは Semantic Web に詳しいようなので釈迦に説法かもしれませんが、 rel 属性と class 属性の仕様上の違いをまず再確認してください。 rel は「リンク形式(のリスト)」、 class は「クラス名(のリスト)」です。リンク形式(link type)がリンクの関係性を表現するのに対し、クラス名は (X)HTML 要素の分類に用いるものです。

いわゆる microformats ではこの二つをちゃんと使い分けていて、 rel 属性は (X)HTML の仕様どおり、リンクの関係性を表現しています。そのリンク先がライセンス文書であると指定したり、リンク先のコンテンツがリンク元とは関係ない(follow してない)と指定する、などです。

一方で class 属性は XHTML に vCard の構造を埋め込んだり、 iCalendar の構造を埋め込んだりするのに使います。クラス名が構造情報と対応しているわけです。

ここまでで明かだと思いますが、檜山さんの記事に出てくる「多重マークアップ」は class 属性の応用の話です。対して、ここで議論しているのは rel 属性の値(リンク形式)をどうするか、という話です。檜山さんの例を引けば、

<寄せ書き>
 <ひとこと 誰="田中">元気で行ってこい。</ひとこと>
 <ひとこと 誰="ミヨ子">おみやげ、忘れないでねぇ</ひとこと>
 ...
</寄せ書き>

ここで言う「誰」属性の値は「田中」がいいのか「id:tanaka」がいいのか「上司」がいいのか「社員」がいいのか「男」がいいのか「日本人」がいいのか「人間」がいいのか「哺乳類」がいいのか「動物」がいいのか「生物」がいいのか… って話と同じですよ。

だから、

つまり rel="hatenab" と rel="delicious" の間に共通性があるのに，その共通性が表現されていないのです．それは，書き手の頭の中だけにあります．

これは勘違いではないですか。上記のとおり、リンク形式に指定する値の粒度をどれくらいにするかというのを議論してるんです。その値の定義は、おのひろきさん自身が言っているとおり「profile によって定義するっていう手」を使います。

profile によって定義するっていう手もありますが，そうすると似たようなサービス全てについて profile で定義を用意しなければなりません．そうではなくて rel 属性では共通性の部分を表現するべきでしょう．

別に「似たようなサービス全て」を定義しなくてもいいんじゃないでしょうか。プロファイル策定者がはてなだったら hatenab, hatenaa, hatenai, hatenad,... と自社のサービスを定義すればとりあえず十分でしょう。これで、あとは API さえあれば、今閲覧している Web ページの作者のはてなブックマークを自分のお気に入りに入れるブックマークレットとか、その人が使っているはてなのサービス一覧を小綺麗に表示する greasemonkey スクリプトとかが作れそうです。

ただ、一利用者の感覚とすれば、hatenab じゃなくて del.icio.us も使いたいんですよね。でも del.icio.us には inbox はあっても「お気に入り」はない。こんなかんじで hatenab と delicious を区別したいニーズはあります。

これについておのひろきさんは

rel="hatenab" とある場合とない場合で，メタデータの抽出の仕方がどう変わるかを考えたら，あまりrel="hatenab"ってのは有効ではないのでは? hatenabにマッチングするか b.hatena.ne.jp にマッチングするかの違いだから．

という見解のようですが、僕はまったく逆ですね。 URI でマッチングしなきゃいけないような設計は悪い設計の代表例だと思います。何で悪いかの理由のひとつは shckor さんがいうとおり URI がやむを得ず変わる場合ですね。 REST とか、疎結合の文脈で言えば、クライアントとサーバのお約束が増えてしまうという意味で悪い設計です。せっかく rel 属性があるのに、関係ないところで URI のコンベンションを作るのは余計な制限を増やすだけだと思います。

ちなみに、はてなや del.icio.us のドメイン名は安定してそうなのでまだいいですが、たとえば、サーバインストール型の Web アプリケーションだったり、社内向けサーバで、どうしてもドメイン名を変更しなければならなかったりしたらどうするんでしょうか。たとえば pukiwiki にソーシャルブックマークプラグインができたとしたらどうしますか。

<link rel="onlineBookmark delicious" href="http://del.icio.us/onohiroki"/>
ってのも良くないと思います．"delicious" ってのを profile で定義しなくちゃならないから．それなら "delicious" を与えるのは title 属性が良いと思うし，profile を定義しなくても良い class 属性のほうが rel 属性よりはまだ良いと思います．

上記のような理由から rel 属性の代わりに class 属性を安易に使うのは反対です。 rel には rel の意味があるのだから。

ここまで書いて、「class 属性を再発見」というエントリが追加されているのを発見したんで、ついでにこちらにも若干コメントを。

最初に定義していなかったものを後から追加したくなったら，別 profile を作るのでしょうか? この問題をどう考えているのかはぜひ教えてほしいです．

同じプロファイルに新しいサービス名を追加してバージョンアップします。もちろんこれは XML のスキーマのバージョンアップ問題と同じ話で、いろいろと難しい問題を含んでいるのですが、どこに追加される可能性があるのかはっきりさせる、新しいものを追加しても問題が起きないようにクライアントを作る(知らないサービスは無視するか、知らないサービスとして扱う)、追加するだけならバージョンを上げなくてもいい(プロファイルの URI を変更しない)、といったような設計が 2005 年の現時点では理想的かつ現実的な設計でしょうね。

shckor さんや yohei さんが言っている事がちゃんと理解できたら title 属性とかぢゃなくて class 属性ってすぐに出てこないとおかしいですよね．いや，未だに shckor さんや yohei さんの主張でよく分からないところがあるけど．

僕は以前にも title 属性は助言情報なのだからコンテンツ作成者の自由にさせるべきという意見を書いたとおり、 title 属性の安易な濫用はお勧めしません。上記のとおり rel から class への安易な鞍替えも同様です。

良い URI の設計

2005-08-12T21:52:00.000+09:00

URI は綺麗であるべき、と常々思っているんですが、よいページを発見しました。 Michael Eakes のこのエントリです。 Tanya Rabourn がリストアップしている文献一覧からエッセンスをまとめてくれています。曰く、よく設計された URI とは

変らない(don't change)

人間が推測可能(are human guessable)

論理的(ファイルシステムを反映する必用がない) (are logical (no need to mirror a filesystem))

サイト構造をビジュアライズするのに役立つ(help visualize the site structure)

短い(are short)

小文字を使う(use lowercase)

予期されない記号を使わない(don't use unexpected punctuation)

問合せパラメータなし(lack query parameters)

公開リンクを許す(allow public linking)

ステートレス(are stateless)

技術を丸出しにしない(dont expose technology)

だそうです。彼のエントリにはそのほかにも Flickr の URI が良い設計例として載っています。

典型的な悪い例はこんな感じかな。

http://test1.example.com/Test/getDocList.cgi?folder-name=abc&user_name=yohei&sessionId=123

直すとこうなる。

http://www.example.com/yohei/abc

最後の項目の悪い例は /home.pl とか /login.do とか /index.jsp とか /hitobito.nsf とかですかね。とりあえずは mod_rewrite を使って解決するんでしょうけど、本質的にはフレームワークが解決した方がよさげ。

Web らしく URI で連携する方向

2005-07-31T23:41:00.000+09:00

前のエントリで触れた ID だけのディスカバリの問題点ですが、他にもこんなのもあります。

僕が自分のブログにはてな ID を埋め込んだとして期待するのは、ブログを訪れた人が自分のブックマークやアンテナを見に来てくれたり、投げ銭してくれたりすることです。でも僕がはてなで何を使っているかは僕にしかわかりません。僕の場合はてブとはてアは使ってるけど、はてダは更新を止めちゃった、はてフは知らん、という状況です。もしかしたらアサマシは嫌いだから投げ銭してほしくない、という人もいるかもしれない。

これって「はてなID」の埋め込みだけでは実現できません。自分ははてなのこのサービスを使っているよ、という主張をできないからです。

ではどうするか。自分ははてなのこのサービスを使っているから見に行ってね、という宣言をしたらどうでしょう。 head 内で宣言するんだったらこんな感じ。

<link rel="hatenab" href="http://b.hatena.ne.jp/yohei" />
<link rel="hatenaa" href="http://a.hatena.ne.jp/yohei" />

body 内部で a タグに書くのであればこんな感じ。

<a rel="hatenab" href="http://b.hatena.ne.jp/yohei" >はてぶ</a>
<a rel="hatenaa" href="http://a.hatena.ne.jp/yohei" >はてあ</a>

ここまでくると、別にはてなに限らないでもいいのではないかという気がしてきます。たとえば僕の場合、使っていると宣言したいサービスは

hatenab
hatenaa
flickr
bloglines
delicious
mixi
blogger

なので、head はこうなります。

<head>
  <link rel="hatenab" href="http://b.hatena.ne.jp/yohei" />
  <link rel="hatenaa" href="http://a.hatena.ne.jp/yohei" />
  <link rel="bloglines" href="http://www.bloglines.com/public/yamamotoyohei" />
  <link rel="flickr" href="http://www.flickr.com/photos/60043209@N00/" />
  <link rel="delicious" href="http://del.icio.us/yohei" />
  <link rel="mixi" href="http://mixi.jp/show_friend.pl?id=173690" />
  <link rel="blogger" href="http://yohei-y.blogspot.com" />
</head>

a タグだったらこうなります。

<a rel="hatenab" href="http://b.hatena.ne.jp/yohei">僕のブックマーク</a>です。
<a rel="mixi" href="http://mixi.jp/view_profile.pl?">mixi</a>も使ってるよ。
<a rel="payment hatenagesen" href="http://nagesen.hatena.ne.jp/yohei">投げ銭</a>よろしく。

この rel= はいわゆる microformats ですね。 link タグなら Atom feed にも同じように入れられます。

rel 属性の値が各サービスごとに違うのがいいのか、もっと別の値がいいのか、そもそもこんなことがやりたいのか、やっていいのか、という話はありますが (^^; URI で繋がるという方向性もある、ということを認知してもらえたらと思います。

そもそも ID を見つけるだけで十分なのだろうか

2005-07-31T22:59:00.000+09:00

なんか複雑な方向になってきたなーと思っていたところで風邪を引いてしまって寝込んでいたので、なんだか浦島太郎状態ですが、思うところを。

今の暫定仕様は僕にとってはちょっと違う方向のように感じるんですね。アカウントの ID だけを渡すというのは、関数のパラメータの一引数を渡すというのに繋がる気がするからです。

そもそも naoya さんがやりたかったことは

まずそもそも僕が考えた仕様は...という前にまず何をしたいかを明確にしないとですね。僕がしたいのは、はてなダイアリーを含めたインターネット上のウェブページ (Permalink) から、そのページを作った人の「はてなのID」を探し出したい、ということです。

ですが、では ID を探し出して具体的に何をするんでしょうか。もちろん、はてなのサービスの中の人はいいと思います。 HTML や RSS/Atom を取ってきて、その中にはてなIDがあれば、その ID からユーザを特定していろいろできる。でも Web 2.0 的に考えるなら、はてな外の Remix する人の事も考えてほしい。

そんな Web 2.0 的な Hatena ID Auto Dicovery の応用に、吉松さんが触れていました。

僕は「投げ銭」に特化しないほうがいいなあ、と思ってます。例えばツールバーに「この人のはてダに移動」とか「このひとのはてブお気にを一覧」とかいうボタン作るのに役立ちそうだな、と思うもので。

なるほど。確かに便利そう。とある Web の記事や RSS/Atom フィードを表示すると、はてなツールバーや Greasemonkey スクリプトでその人のはてなブックマークへのリンクがポップアップしたら楽しい。実際のコード(の断片)は例えばこんな感じかな。

var hatenaid = getIdFromRdfFoaf("http://www.hatena.ne.jp/");
document.write("<a href='http://b.hatena.ne.jp/" + hatenaid + "'>?B</a>");

うーん、嫌だ。

嫌な点の一つ目は "http://b.hatena.ne.jp/" という文字列をクライアント側で持っていて、ユーザ名と組み合わせている点。これをやってしまうと、b.hatena.ne.jp を変えたり、URL の構造を変えたとたんに途方もない数の全クライアントを一斉に変更しなければならなくなってしまう。いわゆる密結合の一番悪いパターンですね。

もちろんはてなのドメイン名や URI の構造がそんなに簡単に変化するとは思いませんが、一般的にはやらない方がいいことです。

それからもうひとつ嫌なのは JavaScript で getIdFromRdfFoaf() を作るのが大変そうなところ。コメントアウトされた RDF/FOAF の文字列を「わざわざ」探し出して、さらにそれをパースして、RDF のトリプルにして…、とやるのは想像するだけで鳥肌が立つ(のは僕だけかな)。

HTML に ID を埋め込む、というのは一見するとすごく汎用的で何にでも使えそうなんだけど、汎用的であるが故に何をやるにも中途半端になってしまう危険性があります。もう少し実用的な使い方をいくつか模索したり組み合わせたりして、その中で汎用的に使える部分を探すという方がいいのではないかと思います。

では具体的には何なのだ、という話は次のエントリで。

Hatena ID Auto-Discovery について

2005-07-23T18:22:00.000+09:00

昨日は SIGMOD-J の大会に行った後にアルファギークなお二人と食事をしてきました。

大会ではやはり naoya さんの Web 2.0 についての話が一番面白かったです。周りにいた人の反応も一緒でした。

ちなみに僕は naoya さんは初対面。食事に途中参加の高林君とはちょうど4年ぶりだったことが今判明。オリンピックみたいだ:-)。

naoya さんは普段から blog やブックマークを見ているので、ぜんぜん初対面な気がしなかったんですが、僕としては REST だの Folksonomy だの microformats だのといった単語をガンガン喋ったり聞いたりするのが新鮮かつエキサイティングでした。やっぱり直接会って話すのは大切だと実感です。

以下本題です。僕は話題に出遅れてしまったんですが Hatena ID Auto-Discovery について。 naoya さんには直接喋ったんだけど、酔っ払っててよくわからなかったと思うので、もう一回ここに書いておきます。

まず、現状の仕様はこうですね。

<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
<link rel="DC.creator" title="id:naoya"
  href="http://www.hatena.ne.jp/user?userid=naoya" />

で、僕が提案するのはこれ。

<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
<link rel="DC.creator" href="http://www.hatena.ne.jp/user/naoya" />

二点提案があります。

最初は title 属性について。例では title="id:naoya" となっていますが、別にこれはなくてもいいのではないでしょうか。 DC の creator は href 属性で指定される URI で識別されるのであって、title 属性はあくまでも便宜上の助言的情報。ならば、title 属性の内容はコンテンツ作成者に委ねた方が自由度が上がる、と考えられます。もちろん id 記法が好きな人は title="id:yohei" としていいし、そうじゃなくて title="YAMAMOTO Yohei" としてもいいし、 title="このページの作者のはてなIDです" とかしてもいいわけです。

次に href でリンクする先の URI についてです。ひとつは ?userid=naoya というように、query string を使うのはどうだろう、という話。もうひとつはこの URI が適切なのか、という話です。

こういう ID としての URI に query string が入っているとちょっとクールじゃないですね。文字列長も長くなっちゃうし、何より query string はクライアント側でいじれる所がいかにも密結合的です。ま、このケースはそんなに気にすることはないんですが、僕のこれまでの感覚だと、はてなは URI がいつも綺麗だという印象があります。はてならしさを維持するためにも、ここは query string を使わないほうがいいのではないでしょうか。

あとはリンク先の妥当性です。はてなダイアリーの id 記法でリンクする先はそのユーザのダイアリーですよね。その観点から id 記法との整合を考えると、ダイアリーを持っているユーザの場合は、ダイアリーにリンクするのが最も適切ではないでしょうか。ダイアリーを使っていないユーザはどうするのかという問題が残りますが、それも id 記法でのリンク先にあわせるのがいいのではないでしょうか。

ということで、最終的には以下のような形になりました。

<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
<link rel="DC.creator" href="http://d.hatena.ne.jp/naoya" />

Atom 1.0

2005-07-17T23:04:00.000+09:00

Atom Syndication Format 1.0 が Tim Bray からアナウンスされましたね。

いろいろなところで言及されていますが、 XML cover pages がいつもながら一番まとまっています。ちなみに RSS/Atom のこれまでの流れは Robert Sayre の記事によくまとまっています。

これで syndication format の本命は RSS 2.0 と Atom 1.0 に絞られたわけですが、これからどうなるか注目です。両者の比較は Tim Bray のもの(日本語版)がありますが、はっきりいって機能的にはそんなに違いませんね。 Atom 1.0 の方が後出しジャンケンなので全体的にすっきりしていますが、普及状態から言うと圧倒的に RSS 2.0 が勝っています。

Atom の方はもちろん syndication format 単体で使えるのですが、 APP(って書くと「アプリ」を想像されそうなので AtomPP) がそろって初めて本領を発揮でしょうから、 AtomPP の標準化までにどれだけ syndication format が普及しているかも重要です。

ちなみに Atom 1.0 フィードの実例を見たい人はここからどうぞ。 blogger は Atom 1.0 に対応してくれるのかなあ…

今後10年

2005-07-15T23:53:00.000+09:00

この weblog のアクセス数がいつもの10倍になっていて、なんだなんだと思ったら naoya さんとこで言及されてました。

Remix や Folksonomy という考え方はすばらしいのだけど、それらを実現する手段としてよりシームレスなものっていうのは一体何なんだろう。使い手がそれらを意識することなしに、その恩恵を得られるもの。自分の両親が blog を使いはじめて整えられたアーキテクチャでウェブサイトを構築し、 RSS や Atom でシンジケーションするということはもしかしたらありえるかもしれないけど、 Greasemonkey で Remix して tagging で情報をうまく整理するなんてことはどう考えてもあり得ない。

Remix とか Folksonomy ってそんなに難しい話なんですかね。 tagging だの microformats だの api だのといった言葉や概念は 10年後にないかもしれないけれど、たとえば自分が撮影した写真を rel="license" で CC ライセンスにして広く共有するとか、逆に CC ライセンスの写真や演奏を検索してそれを基にした二次配布物を公開とか、あるいは Web 2.0 ベースのツールで wikipedia を編纂するとか、 10年後(5年後?)に教育テレビで「ホームページ入門」の一環としてやってるんじゃないかなあ。

と、考えると、これらの世界が実現していくためには今とは違った手段が必要になってくるだろうし、そういった手段が出てこなかった概念はいずれ廃れる、あるいはいわゆるデジタル・デバイド(なんか死語っぽいけど)の象徴になるのかもしれない、なんて風にも思う。手段自体がメジャーシーンに拡大しなくても、 API によって開発された成果物を使う人、 Folksonomy で分類された後の結果だけを見てその恩恵を授かるフォロワーがいたりする、ということもあるので、かならずしも手段のコモディティ化が必須というわけではないのだろうけど。

コンテンツ作成者とフォロワーの間に高速道路が敷かれるんでしょう。つまり、例えばはてなはフォロワーがすぐにコンテンツ作成者になれる道を現在建設中と捉えることができます。これまでは geek の専売特許だったコンテンツ作成とか remix といった行為を普通の人たち(そういう人たちのコンテンツも魅力的)にまで拡大する、それが世界政府御用達システム製造・運用会社や、例の変な会社のミッションなのでは。

Google Maps で世界のサーキット

2005-07-02T02:25:00.000+09:00

自分で見つけられた分

こちらが詳しい

はてなブックマークのタグ編集に Atom PP を用いる件について

2005-06-30T23:49:00.000+09:00

楽しそうなので、考えてみることにする

なにはともあれはリソースのことを考えよう。タグをリソースとするならまずはそれに URI を割り当てなければならない。僕(yohei) の "atompp" というタグの URI は以下のような形式とする。

http://b.hatena.ne.jp/atom/yohei/tag/atompp

次に考えるのはタグリソースの表現に何を使うか。構造を持った情報なので XML になるのはすんなり確定。問題はその形式。候補は以下のとおり。

最新 AtomPP のメンバー要素(member): 長所: 軽い、簡単; 短所: member/@href で参照する先の URL はどの XML 形式にする? あるいはタグ名のテキスト(plain/text)か?
Atom の entry 要素(entry): 長所: 標準。使える子要素がいろいろ定義されている; 短所: (他に比べて)重い。ブックマークの dc:subject との違いがわかりにくい
独自要素(hatena:tag or dc:subject?): 長所: 自由。簡単; 短所: クライアントにとって扱いが難しい。独自すぎる

ここでは entry がいいのではと思うので、それで進めてみる。 entry を選んだのはそのバランスによる。たとえば entry の子要素にはもちろんタグの更新時刻や利用回数も入れられる。タグ名は title に入れるのが素直そうだ。

次はこのリソースに対してどんな操作を行うか。 REST 的に考えると必要そうな操作は取得(GET)、削除(DELETE)、更新(PUT)、新規作成(POST)の四つ。ま、GET と DELETE は必要だろう。 POST で新規作成はいらなさそうだ(タグはブックマーク時に自動的に新規作成されるので)。 PUT で更新できるのはタグ名くらいかな。タグにコメントなんてつけられなくてもいいよね。

さて、これでタグリソースは固まった。今度はタグの一覧を考える。 AtomPP 最新最新版ならコレクションという便利なものがあって、上記どの種類の XML 形式でもひとつのコレクションとして扱える。でもここではタグリソースをあえて Atom entry にしたので、feed 要素を使ってみよう。

一覧取得のときに、オフセットや取得数、タグ名をワイルドカードや正規表現で検索などをしたい気もするけど、そういうのはコレクションリソースの URI の query string でやればよさそうなので、ここでは単純に全タグ取得を考える。

ちなみにコレクションリソースの URI に適用できるのは GET だけ。

以下に例を書いておく。名前空間宣言や X-WSSE ヘッダとか xml:lang とかは省略してるけど許してね。

タグ一覧取得

GET /atom/yohei/taglist HTTP/1.1
Host: b.hatena.ne.jp

HTTP/1.1 200 OK
Content-Type: application/x.atom+xml

<feed>
  ...
  <entry>
    <id>タグの ID</id>
    <!-- Edit URI へのリンク -->
    <link rel="service.edit" type="application/x.atom+xml"
      href="/yohei/atom/tag/atompp" title="atompp"/>
    <!-- title はタグになる -->
    <title>atompp</title>
  </entry>
  ...
</feed>

タグの一括置換というのは要するにタグ名の変更(=リソース title の変更)と考えて、 EditURI に新しいタグ名を PUT する。

PUT /atom/yohei/tag/atompp HTTP/1.1
Host: b.hatena.ne.jp
Content-Type: application/x.atom+xml

<entry>
  <id>タグの ID</id> <!-- いらんか -->
  <title>新しいタグ名</title>
</entry>

タグの一括削除はタグリソースの URI を DELETE する。

あとはタグリソースが URI を持つようになったので、ブックマークリソースのタグ要素(dc:subject or category)からリンクするのがよさそうだ。

Google Maps でみつけたもの

2005-06-27T21:17:00.000+09:00

着陸寸前の飛行機とか走行中の新幹線とか

Microformats の夢

2005-06-19T00:01:00.000+09:00

Microformats の嬉しさについて。

Technorati が推進していることからもわかるとおり、一番わかりやすいのは blog 検索の精度向上だろう。たとえば hReview でブックレビューを書いておけば、たとえば hCalendar でカンファレンスのスケジュールを登録しておけば、たとえば rel="license" で自分の記事や写真を CC ライセンスにしておけば、あなたが提供しているその情報を必要としている人に届きやすくなる。

あるいは今流行の Musical Baton で他の blog にリンクするときに XFN で友人・知人関係を記述しておいたらどうだろう。こんなアイデアを自動化しつつさらに参加者間のリンクを関連で色分けして表示するアプリが作れそうだ。

そんなの前からできたって?
そう、メタデータを駆使したセマンティックウェブを使えば前からできた。 Microformats の価値はそこではない。

そんなの面倒くさそうだって?
そう、これまでは面倒だった。でもこれからは面倒ではなくなりそうな予兆がある。 Microformats が素晴らしいのは、メタデータが簡単につくれることと、メタデータが簡単に利用できることだ。簡単にできる、と言い切ってしまうのは時期尚早だけれども、その希望はある。

たとえばこの Greasemonkey アプリを見てほしい。 Movable Type(だけじゃないけど) の textarea で hCalendar を入力しやすくするための hack である。もうちょっとこのインターフェースがこなれれば Blog サービスに十分標準搭載できそうだ。

あるいはこれはどうだろう。可能性を感じませんか?

Microformats とは何か

2005-06-16T23:58:00.000+09:00

Web 2.0 の図の中でたぶん一番なじみがないのが microformats だと思う。

現時点で microformats の日本語の解説で一番詳しいのは NII の武田先生のこのポストだ。

そもそもMicroなのかというと，既存の大量な詳細なドキュメントで規定される人間が読むことができないようなフォーマット("megaformat!")に対して，format自身も小さいし，簡単に理解できるようなフォーマットだから，ということでしょう．

セマンティックウェブの先端研究者の方による解説なので、Web 2.0 に興味のある方はぜひ読んでください。

REST -> AtomPP -> blog -> Permalink -> RSS/Atom -> Remixing (Ajax/Microformats/Folksonomy)

2005-06-10T23:54:00.000+09:00

少し前の話だが、Blog Hackers Conference 2005 に行った。 miyagawa さんのキーノートも、naoya さんの講演も、キーワードは Web 2.0 (的なもの)だなという印象だった。

中でも特に気になったのはこのスライドで blog が missing piece を埋めた、という話だ。こちらのコメントにも書いたのだけれど、ここでいう blog というのはいわゆる weblog system/service だけを指すのではなくて、 blog 周辺の技術 (RSS, Atom, AtomPP, REST, Permalink) が方法論として、プラットフォームとなる、というのがまっとうな解釈であろう。

僕自身もこのような Web 2.0 的なものが現在の主要な関心事になっていて、それをまとめたのがこの図である。

まず REST。 REST の詳細は REST 入門を見ていただきたいが、ここでいいたいのは REST アーキテクチャスタイルの Web がすべての基本となる、ということである。どんなサービスやアプリケーションを作るにしても REST は避けて通れない。

次に Atom Publishing Protocol (AtomPP; いわゆる AtomAPI) である。 AtomPP は REST で足りないところをきれいに補完するものだ。 RESTful Web で URI 経由でリソースに CRUD を適用できるようになっただけでは、まだ難しい。 AtomPP は REST の URI+CRUD でコンテンツをどう編集するかを具体的に規定した(する)プロトコルとして価値がある。また AtomPP はその汎用性と拡張性から、 80/20 の法則で、ほとんどの Web サービスのベースとなるのではないかと予想する。

次に blog system/cms である。Wiki も含む。これは REST ベースの AtomPP 上に実現された、まさにプラットフォームである。 blog/cms がもたらした効能はたくさんある。まず第一に Web 上のコンテンツ作成の敷居を大幅に下げた点。次に、(X)HTML の長年の夢である文書構造とスタイルの分離を推進した点。さらにその進化版として、構造化文書+メタデータの作成を簡単にすることも期待される。そして最も大きいのは各種最新技術のテストベッドとして、アルファギークの格好のおもちゃとなっている点である。

Permalink は REST の思想のひとつだ。すべてのリソースはそれぞれ URI を持つ。もちろんこのときに "Cool URIs don't Change" であるべきだ。この永続的な URI を手作業で作成・管理していくのは難しい。昔ながらの Web サイト作りではどうしてもリンク切れが発生する。しかしそれも blog システムや CMS の普及でツールに任せる時代がやってきた。また、AtomPP はもちろん Permalink をベースとしている。

みなさんご存知の各種 RSS および Atom Syndication Format はコンテンツ配信、特に syndication が目的だ。 Permalink, blog, AtomPP と組み合わせることで、浮動的なコンテンツを実現する。 (TODO もうちょっと RSS/Atom の本当の価値を検討する必要があるな)

少し毛色が変わって Folksonomy は tagging やはてなブックマークのようなゆるいソーシャルサービスも含む。こいつがすごいところは、コンテンツ作成者以外にコンテンツとメタデータ作成の門戸を開いたところである。それまで、ブロガーが独占してきたコンテンツ作成という特権を、 blog を書かない大多数の人々に tagging やコメントという形で開放したところである。もちろん大勢の人々によるメタデータの補完という価値もある。ちなみに、ソーシャルブックマークで tagging するためには、もちろん Permalink が必要である。

Microformats が実現するのはコンテンツの更なる細分化である。 Permalink で記事単位になったコンテンツを semantics で分解してプログラムからアクセスできるようになる。現状では microformat なコンテンツを作成するハードルは高いが、これは blog/cms がじきに解決する問題だろう。

Ajax、ここはいわゆる Ajax だけじゃなくて greasemonkey とか動的言語とか、そういう気持ちも入っている。 simple で practical な hack 環境。

そして、最後に行き着くところは Remixing Culture である。 REST/AtomPP/Permalink でコンテンツ編集のためのアーキテクチャが整い、その実装としての blog システムが整備され、 RSS/Atom でコンテンツが再編集しやすい形で配信し、 Folksonomy/Microformats でセマンティクスが補完され、 Ajax で Remix する。

若干酔っ払ってるのでまとまりないですが、最近考えてるのはこんなことです。

CDF を…覚えていますか?

2005-06-02T22:26:00.000+09:00

CDF を覚えている人はいるだろうか。

たとえばこのファイルをダウンロードして、デスクトップに保存してみてほしい。 Windows を使っている人なら、アンテナのアイコンが現われるはずだ。

ためしにダブルクリックしてみよう。あやしげなダイアログボックスが表示されるだろう(キャンセルしといてね)。

右クリックしてみよう。いっぱいメニューが出てくるはずだ。

エディタで開いてみよう(「右クリック→編集」でもよい)。タグ名が大文字の見なれない XML ファイルである。

これは XML の創世記に話題となった Channel Definition Format (CDF) だ。

覚えていない人、あるいはそもそも知らない人のために解説すると、 CDF は XML の最初のアプリケーションとして 1997-1998年当時に大変注目されていた技術である。タグ名が大文字なのも、当時としては普通のことだった(あのころ僕たちは HTML のタグを大文字で書いていた)。村田さんの「XML 入門」(この本が書かれたのは'97年で XML の勧告化前)でも、 XML の応用例として最初に CDF が登場している。

この CDF はプッシュ型 Web キャスティングのために開発された規格である。プッシュ型 Web キャスティングというのは、ユーザが Web ページをいちいちチェックしなくても、 CDF 対応クライアントが CDF ファイルを定期的にチェックして、更新があったときだけ通知してくれる機能のことだ。

鋭い人ならもう気付いている思うが、この機能は現在我々が RSS でやっていることと、基本的には全く同じなのである。

当時、現在の RSS リーダーはまだ一つもなかった。ではいったい何で CDF を受信していたのか。それは PointCast (あー懐しい)や Windows の ActiveDesktop あるいは IE 4.0 などだ。 PointCast はもうとっくに廃れているけれど、 Windows や IE はまだ現役なので、我々のデスクトップにアンテナアイコンを表示してくれるのだ。

(hr タグを使うのも久しぶりだなあ…)

さて、なんで今さら CDF の話をしたのかというと、 naoya さんのこの記事を読んだからだ。いわく、一度はキャズムを越えられなかった RSS が、 blog という最良の伴侶を見つけてキャズムを越え爆発的に普及した、ということである。

技術的にはそんなに違わないのに CDF はキャズムを越えられなかった。当時でも CDF を理解して PointCast を使っていたのはギークだけだろう。それ以外の何万(もっとかな)のユーザは CDF なんて知らずに PointCast で天気予報と朝日新聞を見ていたのだ。でも CDF は死んだ。

RSS も粘って粘ってやっとキャズム越えた。 blog ツールによりすべての人々が RSS を提供できる仕組みができたからだろうか。僕にはわからない。

コンセプト/アイデアはいいのに死んでいった技術の中にも、復活するものがあるのかもしれない。ただし、復活させるには駄目になったときとは違うグループがやる必用がある。たぶん。

冒頭の CDF は Sam Ruby さんのものです。

REST 入門(その10) 終わりに

2005-05-30T20:07:00.000+09:00

» REST 入門目次

前回まで、REST 入門ということで、 REST アーキテクチャスタイルとは何なのか、について基礎的なところを結構細かく :-) 説明してきました。 REST 入門はこれで終わりですが、最後にロイ・フィールディングの論文から REST アーキテクチャスタイルの各制約を抜き出して説明します。

Null スタイル: 最初は、制約がまったくないところからはじまります。それが Null スタイルです。
クライアント・サーバ: 最初の制約はクライアント・サーバです。REST がクライアント・サーバから派生していることは、 "2. アーキテクチャスタイルとは" で解説しました。
ステートレス: REST スタイルにおいて、サーバはクライアントの状態を管理しません。すべての状態はクライアントで持ちます。クッキーでの状態管理が REST でないことは "8. REST でないもの" で説明しました。
キャッシュ: REST スタイルではサーバが返す結果をクライアントでキャッシュ可能なように設計します。これによりネットワーク効率を向上させることができます。
統一インターフェース: REST の制約で最も特徴的なのがこの統一インターフェースです。クライアントはどんなシステムとでも同じインターフェースで接続できます。統一インターフェースについては "4. HTTP GET -- その絶大な効果"と "5. 四つの動詞 -- GET, POST, PUT, DELETE"で説明しました。
階層化システム: このシリーズでは説明しませんでしたが、REST スタイルの制約にシステムを階層化できることがあります。これにより、たとえばロードバランサーでの負荷分散や、レガシーシステムのラッピング、proxy サーバなどが可能になります。
コードオンデマンド: この制約も説明していません。 REST では、クライアントがコードをサーバからダウンロードして実行することができます。たとえば Javascript ですね。ただし、この制約はオプションです。

終わりに

僕がこの REST 入門シリーズを書いた目的は二つあります。ひとつは「目次」で書いたとおり、日本語での REST の基礎的な資料を作るためです。日本では Amazon Web サービスの REST API のような単純な XML over HTTP としてしか REST が認識されておらず、往々にして間違った議論がされていたり、あるいはアーキテクチャスタイルとしての REST が注目されていなかったりします。しかし REST は Web における次の5年の(もっとか?)基盤技術であると、僕は思っています。各個人がどう評価するかはともかく、REST を知らずに Web を語ったり議論したりするのは非常に危ういと思うのですね。そういう意味で、REST 周辺の言葉を整理して (Architectural Style の日本語訳も悩んだのです)、日本でもちゃんと話ができるようにしたかった。結果としては naoya さんに紹介してもらって僕の weblog のページビューも10倍くらいになりましたし、 WWW2005 後くらいから REST で検索してくる人が非常に多くなったので、このシリーズをやってよかったなと思ってます。

もうひとつ、僕が言いたかったことは、せめて技術者が技術に接するときは純粋にそれを技術として評価しよう、ということです。 SOAP や WS-* の世界は、ベンダの対立など半ばゴシップ的な記事が IT 系ニュースサイトの紙面を躍らせるので、どうしても脊髄反射的に「だから WS-XX は駄目なんだ」とか言いたくなるのですが、それは変なんですよね。 WS-* は確かに重くてすべてを理解するのは大変なんですけど、 Microsoft や IBM が無意味にあんなにリソースを割いて推進するわけがないのです(ハロウィン文書の例の戦略だ、というハナシもありますが)。

たとえば WWW2005 のパネルで SOAP/WS-* を厳しく批判していた Tim Bray や Adam Bosworth は SOAP/WS-* のことを何も知らずに批判しているわけではないのです。むしろ、知っているからこそ批判できるんです。 SOAP/WS-* 側の人間にしても同じです。 Don Box や Jeffrey Schlimmer, Dare Obasanjo, Tim Ewald, Dave Orchard みんな REST のことはきちんと知っている。だいたい Dave Orchard と Tim Bray なんてランチしてたりするし、その他の人々も W3C のメーリングリストやミーティングなんかでちゃんと交流して議論しているわけです。そういえば Tim Bray だって昨年の XML Developers' Conference (Microsoft よりのカンファレンス)で講演してました。

とまあ、僕も偉そうなこと書いてる割に REST をきちんと評価したのは昨年の8月くらいだったりします。それまでは Web サービス = SOAP/WSDL で RPC だったんですが、 document/literal になってからイマイチわからなくなってしまった。で、いろいろ調べたり考えたりしてやっと REST にたどり着きました。「REST は XML の王道」とかキャッチーなことも書いてますが、 REST 万歳、SOSP/WS-* ダメダメと言うつもりはなくて、両方ちゃんと評価しよう、ということです。

この weblog の今後ですけど、シリーズものだと普段はあまり気が乗らない基本的なことも書く気がおきてよい感じなので、もう一回やってみようかと思ってます。題材は今話題の(?) Web 2.0 にするつもり。ではまた。

REST 入門(その9) REST と SOAP

2005-05-28T21:39:00.000+09:00

» REST 入門目次

前回、WWW のうち REST アーキテクチャスタイルに従っていないものについて解説しました。今回は「その筋」では有名な REST と SOAP の対決の概略を解説します。

Google で "REST vs SOAP" あるいは "SOAP vs REST" を検索すると、たくさんの Web ページが見つかります。いろいろな立場の人が、それぞれの意見を述べ合っていて、ここで全ての主張や意見を解説するのは不可能です。これから解説する内容は、あくまでも個人の意見ということをご了承ください(まー weblog なんてそんなもんですが)。

ところで最初からこんな話をするのもアレですが、 REST と SOAP は比べられるものなのでしょうか。 REST はこれまで何度も述べてきたとおり、ネットワークシステムのアーキテクチャスタイルです。一方で SOAP はプロトコル、あるいはメッセージのエンベロープ形式です。二つを比べようにもあまりに次元が違い過ぎます。この二つが並べて議論されるとき、たいていは SOAP を拡大意解釈するか、あるいは REST を縮小解釈しています。たとえば Amazon Web サービスの SOAP API と REST API を比べたり(REST の縮小解釈)、あるいは SOA と REST を比べたり(SOAP の拡大解釈)。これには歴史的理由がいろいろあって、紆余曲折してきているというのが真相です。ここでは時系列に沿って、REST vs SOAP を振り返ってみたいと思います。

SOAP RPC と REST

2000年ごろ、Web サービスといえば SOAP/WSDL/UDDI でした。 SOAP には何種類かの使い方があるのですが、このころは SOAP エンコーディングを使った RPC (SOAP-RPC)が主流の使い方でした。 SOAP-RPC がやりたいこと(できること)は非常に単純です。異なるプラットフォーム同士で RPC をすることです。

プラットフォームが異なる場合、標準的なデータフォーマットが必要となり、そこに SOAP エンコーディングという XML を採用したプログラム言語のデータ構造のシリアライズ形式が使われました。 SOAP エンコーディングを使った RPC は WSDL の記述の仕方から rpc/encoded と呼ばれます。

SOAP-RPC は便利です。それまで RPC がなかなか実現できなかったところで RPC が可能になりました(たとえば UPnP)。しかし、SOAP-RPC は結局のところ RPC ですから、それ以前の RPC や DCOM, CORBA などの分散オブジェクト技術が持っていた問題をそのまま受け継ぐことになります。サービスの呼び出し単位は細かく、オブジェクトが状態を持ちがちなので、スケーラビリティが問題になります。そのような理由から SOAP のトレンドは SOAP-RPC から別のものに移っていくことになります。

WS-*/SOA

rpc/encoded よりも粒度が粗く、RPC でなく XML をそのままメッセージとして送信する、そんな SOAP のやり取りを document/literal 形式といいます。これは引数が DOM の Document オブジェクトひとつのメソッドを思い浮かべればいいでしょう。 XML を DOM でそのまま渡して、結果も DOM で返ってくる。非常に単純化するとそんな形式です。

一方で SOAP の世界には WS-* と呼ばれる仕様群が登場します。 SOAP 自身は前にも述べたとおり単なるメッセージエンベロープ形式であり、実際の運用ではさまざまな機能をその上に実装する必要があります。各社バラバラにそれらの機能を作っていってもいいのですが、ある程度共通化して使える機能に関して WS- という接頭辞をつけた名前の仕様書がさまざまなベンダから提案されました(されています)。具体的な仕様書名を挙げれば、たとえば WS-Security や WS-Addressing などです。

この WS-* 仕様群には、ベンダ各社の標準化競争だとか、オーバースペックだとか CORBA の再来だとか、さまざまな問題が指摘されています。が、まあここではそういう話はおいておいて、純粋に技術的にどうなのかという議論をしたいと思います。

REST と SOAP

ここでは SOAP といったときに単純に SOAP エンベロープ形式を指すわけではありません。 SOAP というのはその周囲の WS-* だとか SOA だとかを含んだ一連のコンセプトを指すと考えます。

SOAP 的な考え方と REST 的な考え方(というか REST は考え方そのもの)の一番の大きな違いは、プロトコル独立を重視するかどうかです。 SOAP 的考え方はプロトコル独立を重視します。たとえば SOAP メッセージは HTTP でも SMTP でも UDP でも直接 TCP でも送れるように設計されています。一方で REST には HTTP しかありません。この両者の差は何なのでしょうか。

この差はインターフェースがどこに含まれるかの違いです。 REST では uniform interface 制約ということで HTTP が統一のインターフェースとなります。 HTTP の上をデータ(XML)が流れます。一方で SOAP ではトランスポート独立ということで TCP, UDP, SMTP, そして HTTP の上に getX, startY などのインターフェース付きのデータ(SOAP メッセージ)が流れます。

REST と SOAP 的考え方の違い、少しだけですが雰囲気はつかめたでしょうか。このテの話題は純粋に技術的ではなく、他の要素が絡むので語りにくいのですが、技術者の皆さんに言いたいのは REST でも SOAP でも、せめて技術的にはニュートラルに評価しましょう、ということです。今日のこのポストもかなり端折って書いているので、このまま鵜呑みにするんじゃなくて自分で調べてくださいね。

この REST 入門シリーズも次回はとうとう最終回です。

Alpine

2005-05-25T23:33:00.000+09:00

前のエントリの続き。

同論文では Alpine の設計目標が提示されている。

Stay in the XML space as much as possible.

Take advantage of as much leading edge infrastructure as we can.

Adopt the the handler chain pattern of Axis/JAX-RPC.

Target SOAP 1.2 (POST only, WS-I Basic Profile 1.1)

Document/literal mssages only, not RPC/encoded.

Support XSD and Relax NG schemas.

Run server-side, client-side, and as an intermediary.

No support for JAX-RPC or JAX-M/SAAJ APIs.

Configurable procedurally, through the Java Manage- ment API (JMX).

Permit dynamic handler chain configuration during mes- sage processing.

One supported parser.

Run on Java 1.5 and later.

No provision of side features such as a built in HTTP server, or a declarative configuration mechanism. These are delegated to other products.

この中でも注目は 1 と 3 だ。

XML の API として、彼らは XOM を念頭においているようだ。ハンドラチェーンを使うのは「知っている XML だけを処理する」モジュールを接続して処理をするためだろう。

いやーしかし、こういう論文が Sun でも IBM でも BEA でもなく HP から出てくるところが、面白いなー。

Java SOAP スタックの再考

2005-05-25T23:04:00.000+09:00

とても興味深い論文を読んだ。 Steve Loughran と Edmund Smith の "Rethinking the Java SOAP Stack" だ。この論文は現在の Java の SOAP 実装スタック、特に JAX-RPC の問題点を XML セントリックな視点から明確に指摘している。また、最後の部分で Alpine という新しい SOAP スタックのコンセプトを提案している。

Alpine の方はまだどんなものかわからないので、これからに期待したいが、 JAX-RPC の問題点の方はとても面白い。雰囲気を伝えるために論文の第二章 "基本的な JAX-RPC の欠陥(The Fundamental Flaws of JAX-RPC)" の見出しを日本語で引用する。

オブジェクト/XML のインピーダンスミスマッチ

XML 要素の Java クラスへのバインディング

XML の名前(Names)の Java 識別子へのマッピング

Enumeration

ポータブルでない型

オブジェクトのグラフの直列化

XML メタデータと名前空間

メッセージ妥当性検証

XML と直列化データの不適切な混和

フォールト処理

SOAP は RPC ではない

SOAP は RMI ではない

WSDL: 別の複雑さ

このように論文で指摘されている問題点はいくつもあるのだが、基本的には SOAP/XML Web サービスを Java 世代のプログラミング言語(Java に加えて C#, VB.NET も)にネイティブにマッピングしてしまうことへの批判となっている。その中でも特に大きいのが XML とオブジェクトのデータモデルの違いに起因するインピーダンスミスマッチだ。ここで指摘されている各事項は、XML をオブジェクトにマッピングしたり、オブジェクトを XML にマッピングしたりすることが本質的に難しいことを示している。

上でも述べたとおり、この論文は XML セントリックな視点から記述されているので、逆に RPC/RMI/Object セントリックな視点から見るとまったく許容できない内容なのかもしれない。そういう意味で面白い文(Don Box も引用している)がある。

我々は Web サービス開発者にはただ二つの分類があると考える。 XML に満足していてそれを扱う仕事をしたいと願っている人々と、満足していないのに結局はなんだかんだいってそれを扱う人々だ。

(We believe that only two categories of web service developer exist: those who are comfortable with XML and want to work with it, and those who aren’t but end up doing so anyway.)

明らかに僕は前者だ :-)

Blog Hackers Conference 2005

2005-05-24T21:55:00.000+09:00

Blog Hacker じゃないけど、金曜日 Blog Hackers Conference 2005 を聞きに行きます。たまにはこういうところも行かんと。 REST/Web サービスな人と時間があれば交流したいもんです。メールか mixi で連絡ください。って誰あてだ ;-)

疎結合と XML

2005-05-23T22:07:00.000+09:00

疎結合(loosely-coupled)って何でしょう?

僕自身、適当に疎結合という言葉を使ってしまいがちですが、ちゃんとした説明なり定義なりが必用だと感じています(自分のために)。いいかげんな定義で話をはじめると、各人の方向性がずれまくって議論ができないですよね。 Web サービスしかり、 SOA しかり、REST しかり。ということで今回は僕なりに疎結合ってこんなもの、というのを考えてみます。

ものすごく一般化してしまうと、疎結合というのは複数のコンポーネント間の結び付きがゆるいことを指すんでしょうね。たぶん、ここまでは誰でも同意してくれるはず。ただこれだけでは議論ができなくて、このコンポーネントに何をもってくるかを決めて、はじめて具体的な話ができます。

僕がここで話したいのは Web サービスの文脈での「疎結合」ですから、コンポーネントは Web サービスになります。コンポーネントがオブジェクトだとかもっと細かいレベルの話もあると思いますけど、ここではしません。

あ、Web サービスという言葉も危いですね。ここでは Web 上で機械(プログラム)可読なフォーマットで情報を提供するもの、だとします(実際、僕の Web サース感はこれに近い)。 SOAP インターフェースの株価サービスかもしれないし、 AtomAPI のはてなブックマークかもしれない。 RSS フィードも含みます。

ところで、この「疎結合」をもろに扱った本があります。タイトルがずばり「疎結合」です。 SOAP よりの Web サービスの文脈での疎結合を扱っている本です。この本は10章で疎結合とは何かを解説しているんですが、そこにはこんなことが書いてあります。

(前略) 多くの人々が「疎結合」という言葉を口にしますが、その意味を正確に説明できる人はほとんどいません。これは、疎結合が方法論もしくは作法であり、確立された規則や仕様ではないからです。

疎結合は、俊敏性(アジリティ)、すなわち変化に適応する能力を重要視する分散アプリケーション設計へのアプローチの一種です。 (後略)

つまり疎結合というのは分散アプリケーションの作り方、設計の仕方に関する考え方のひとつであり、特に決った規則や仕様はないってことです。これは逆の意味でしっくりきました(僕には)。これだけ曖昧な定義なら、議論の方向性が定まらないのも仕方ないですね。

僕が今考える疎結合システムのイメージはこんな感じです。

まず、サービス(コンポーネント)間のインターフェースは統一し、半永久的に変更しません。サービスのインターフェースに少しでも修正が入ると、旧インターフェースを利用していたクライアントを修正しなければならないからです。

インターフェースを統一して不変にしたときに、ではいったいどこでサービス同士の機能を差別化するのか。それはサービス間でやり取りするデータで行います。データ形式を思いっきり自由に拡張可能にして、どんな種類のデータでも統一インターフェースで受け渡し可能にします。オブジェクトだとこの拡張性が厳しいのですが、 XML と名前空間の組み合わせならぜんぜん問題ありません(ちょっと言い過ぎか)。

XML が拡張可能ということは、自分が知らない要素や属性が出てくる可能性があるということです。でも、そんな拡張された未知のデータでもエラーにせずに、使えなければなりません。そのために、知らない要素は無視する、という動作をデフォルトで行わなければならないのです。 SOAP の mustUnderstand 属性がデフォルトで false なのは、こういう理由からではないかと思います、たぶん。

で、このデフォルトで無視という動作は、吉松さんがこのポストで言っている「無邪気なまでにデータの読み手に解釈をゆだねる姿勢」のデータの読み手側の一番簡単な実践なんだと思うのです。本当はさらに吉松さんのポストのコメントで萩原正義さん(らしき人)が言っている「semantics を重視した…」というのも直感的にわかりそうなのだけれど、今の僕には残念ながら理解しきれません。だからとりあえず、 XPath なりで知ってる要素と属性をパターンマッチして知らないやつは無視、からやってみるしかないんだな、というなんだか当たり前の結論になっちゃったなあ。

REST 入門(補足2) POST と PUT

2005-05-22T10:49:00.000+09:00

» REST 入門目次

kwatch さんから以下のようなコメントをもらいました。

POSTとPUTの説明が逆では？たしかPUTが新規作成であり、POSTは送ったリソースの処理を指定したURIに任せるということだったと思いますが。

コメント欄では返答が書ききれなかったので、補足として新しいポストを追加します。

RFC2616 では PUT の動作が二つ規定されています。

指定した URI がすでに存在している場合: PUT はその URI のリソースを修正(更新)する
指定した URI が存在しない場合: PUT はその URI のリソースを新規作成する

PUT を規定している 9.6 節には POST と PUT の違いとして以下の記述があります。

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

つまり PUT でも POST でもリソースを新規作成することができるのですが、以下の違いがあるということです。

PUT でリソースを新規作成する場合: クライアントが指定した URI のリソースが新規作成される
POST でリソースを新規作成する場合: クライアントが指定する URI はリソースを新規作成するリソースの URI。新規作成されたリソースの URI はサーバが決定する

ここまでは HTTP 1.1 の規定の話です。論点は、リソースの URI を PUT でクライアントが作るのか POST でサーバが作るのか、ということです。 REST では URI はクライアントにとって不透明(opaque)であるべき、という原則があります。そのココロはクライアントとサーバの結びつきをなるべく減らす、というものです。 PUT でリソースを新規作成する場合、クライアントはそのサーバが提供する URI 空間の管理方法を別途知らなければなりません。このような密結合は REST あるいは Web サービスの世界では厳禁事項の一つです。

たとえば現状の Atom Publishing API では、新しいリソースの作成はコレクション URI に POST することになっています。

REST 入門の一連のポストこのような理由から、リソースの新規作成は POST で行う、と説明しています。

まっとうなソフトウェア工学に期待すること

2005-05-21T18:35:00.000+09:00

naoya さんのダイアリーに端を発してちょっとだけ議論が起きている。

まず naoya さんのオリジナルのポスト。はてなが従来のいわゆる世間一般の開発手法を採用せず Perl でアジャイルな開発手法をを選ぶ理由として、その開発するソフトウェアサービスの性質と動的型付け言語の開発効率を挙げている。

対してオリオナエさんは naoya さんがソフトウェア工学を軽視している(ように見える)点を、薬学と建築工学の例を使って批判している。

吉松さんははてなのサービスとオリオナエさんの薬の例のギャップを指摘して、いわゆるソフトウェア工学的手法に疑問を投げかけておられる。

Don'tStopMusic さんもオリオナエさんの例とはてなの違いからいわゆるソフトウェア工学(と Java)ははてなには合わないという主張だ。

ここまで読んで思ったのは、みなさんの「ソフトウェア工学」感のずれだ。それぞれソフトウェア工学に期待することが微妙にずれているので、どうしても話がかみ合わないように見受けられる。

そんなときに思い出すのは檜山さんのこの文書だ。

檜山さんの記事を読むまでは僕もいわゆるソフトウェア工学に胡散臭さを感じていた。だからといって職人芸的なアプローチについても、なんだか割り切れないものを感じていたのも事実だ。僕はもともとは情報系の人間ではなく、学部ではロボットで遊んでいた人間なので、ロボットの基本である機械工学といわゆるソフトウェア工学の差があまりに激しいのでびっくりしていた。そんなところで檜山さんの言葉「どうでもいいソフトウェア工学」と「まっとうなソフトウェア工学」を得て、やっとすっきりした。

たとえば REST アーキテクチャスタイルはまっとうなソフトウェア工学の貴重な研究成果だと思う。もちろん REST を適用すれば何でも解決するわけではない。でも REST スタイルを学んで設計開発するのと、何も知らずにどうでもいいソフトウェア工学で設計開発するのでは、その結果の Web アプリケーションの品質や性能に大きな差が出るだろう。

それからはてなの成果、はてなフレームワークは Web アプリケーションフレームワークの実践としてとても素晴らしいものではないかと予想しているのだけれど、それが優秀なハッカーの職人芸的な成果としてしか扱われないのであればとてもさみしいことだと僕は思う。はてなフレームワークがオープンソースになったあかつきには、アカデミックな研究者の方にぜひ、その成功の秘訣をソフトウェア工学観点から解析してもらって、それ以外のフレームワークに広く展開できるような研究成果をだしてもらえないものだろうか、と期待している。

今週は濃かった

2005-05-14T21:44:00.000+09:00

今週は濃い1週間だった。火曜日に檜山さん、川俣さんと食事。金曜日は WWW2005 で天笠さんとお茶。その後パネルを聴講して、会場で村田さん、吉松さん、平野さんにお会いした。その後は幕張勤務の Shu 君と久々に会った。脳みその心地よい疲れ。

Web Services Considered Harmful?

2005-05-14T01:20:00.000+09:00

WWW2005 のパネルディスカッション "Web Services Considered Harmful?" に行ってきた。いやー楽しかったなー。パネリストは

という超豪華メンバー。以下、簡単にメモです。しょうもないメモですみません。他のブログでまとめているのを見つけたら、更新しておきます。

まず Rohit Khare から背景の説明
SOAP, WSDL から 5年
WS-* 問題
表面的には標準化の問題
実際は技術の問題

Tim Bray
Web サービス二つの側面
ひとつはネットワーク越しの API
もうひとつは XML で表現されたメッセージ交換
WS-* はあほみたいに仕様書のページがある

吉松さん
Amazon Web サービスの紹介
なぜ Amazon が Web サービスをやるか→ニーズがあったから
SOAP: 20%, XML over HTTP: 80%
Amazon Web サービスを使ったアプリの紹介
Why they are builgding?
because it's live!

Mark Baker
Web より祖結合なシステムはあるのか
やろうとしていることはアプリケーション間でのドキュメント交換
それを以下に単純に、疎結合で、ドキュメント指向でやるか
二つの方法
1 SOA
それぞれのアプリにそれぞれのインターフェース
→インターフェースを共有できない
2 SQL/MOM/EDI-inspired
同じインターフェースなら共有できる
その同じインターフェースが HTTP
これが Web (そして REST)のすべて

Adam Bosworth
タイトル: A Web of Data
Web 成功のつぼ
→simple, sloppy, standards, scalable
MySQL Users Conference 2005 と大体同じような話
networks are faster than disk とか
9年前のビジョンが実現されていない
XQuery のように遅かったり
XSD みたいに動かなかったり
末端ユーザが使えないくらい難しかったり
この人の話は面白すぎてメモとりきれなかった
ひとつだけ書けば、REST にも WS-* にも足りないものとして非同期性が挙げられていた

この後の自由討議は Mark が書いているとおり Tim と Adam の二人舞台だった。特に Adam Bosworth がクールでスマート。いってることは過激というか強烈というか痛烈というか、まあ彼のブログのとおりなのだけど、本当に賢くて理に適っている。

そういえば聴衆からの質問者で一人 Web サービスよりの人がいたんだけど、 Mark の blog によればあれは Hugo Hass だったみたい。

100人くらい入る会場はほぼ埋まっていた。半分以上は外国人だったと思う。終了後村田さんから聞いたのは、 REST のための XML 開発者の日をやりたい(やりたかった)が事務局がないのでできない、というような話。僕も日本でももう少し REST がメジャーになった方がいいと思っているので、なんとかできないかなーと最近考えてます。

[update: 2005-05-14-01] 吉松さんの感想

[update: 2005-05-14-02] 会場の写真(吉松さんの Flickr 撮影者は平野さんみたい)

[update: 2005-05-14-03] 村田さんの記事 Adam Bosworth のこの採点表はメモしきれなかったところなのでうれしい!

[update: 2005-05-15] 吉松さんのまとめ

>[update: 2005-05-16]平野さんのまとめ

REST 入門(その8) REST でないもの

2005-05-12T23:11:00.000+09:00

» REST 入門目次

WWW は REST アーキテクチャスタイルのアーキテクチャを採用した実装のひとつですが、 REST アーキテクチャスタイルでないアーキテクチャの WWW アプリケーションもかなり存在します。 REST でないものを一言で言ってしまうと、 URI と HTTP を正しく使っていないもの、ということになります。以下では URI と HTTP の誤った使い方について説明します。

URI をクライアントで組み立てる

URI をクライアント側でごちょごちょ組み立てなければならないのなら、それは REST ではありません。たとえば、はてなブックマーク AtomAPI が、こんなインターフェースだったらどうでしょう?

ブックマークをキーワードで検索する。

POST /uso/bookmarkSearchService HTTP/1.1
Host: b.hatena.ne.jp
Content-Type: application/xml

<keyword>REST</keyword>

レスポンスはブックマーク ID のリストになる。

HTTP/1.1 200 OK
Content-Type: application/xml

<resultList>
  <result id="332"/>
  <result id="55"/>
  <result id="9842"/>
  <result id="102944"/>
</resultList>

クライアントは /resultList/result/@id を見て、ブックマークの ID を知る。そのブックマークを GET するには、ブックマーク取得サービスに ID をパラメータで渡す。

GET /uso/getBookmark?id=332 HTTP/1.1
Host: b.hatena.ne.jp

なんか、変ですよね。 REST であれば、ここは当然ハイパーリンクで実現すべきです。

GET の濫用、または URI へのアクションの挿入

この問題は前節の問題とビミョーに絡んでいます。例を見てみましょう。ブックマークを削除するときに以下のような操作をするとします。オペレーションが削除であることは action パラメータで指定して、削除するブックマークは id パラメータで指定します。

GET /uso/bookmarkService?action=delete&id=332 HTTP/1.1

この方式がまずい点は二つあります。ひとつは前節で述べたとおり URI をクライアントが組み立てなければならない点。もうひとつはオペレーションを action というパラメータで URI に組み込んでいる点です。

action パラメータを URI に埋め込むのが駄目なのには理由が二つあります。第一に HTTP メソッドのセマンティクスを正しく利用していない点。 HTTP にはきちんと DELETE メソッドがあります。しかし、上の例では DELETE を使わずに、GET を使っています。これは明らかに誤用です。

この例が駄目な二つ目の理由は GET でリソース副作用(side effect)がある操作をしている点です。 GET の重要な性質としてリソースに副作用を与えないということがありました。しかし、この URI を GET をすると、URI が指定するリソースが削除されてしまいます。これはセキュリティ上重大な欠陥となる可能性が強い HTTP の誤用です。少し前に話題だった CSRF の一番典型的なパターンは、この GET の濫用でしょう。

POST の濫用

すでにその5で POST の濫用については説明しましたので、ここでは簡単に振り返っておきます。 POST は四つの HTTP メソッドの中で一番柔軟なメソッドです。しかし、HTTP メソッド本来の意味を考えて POST メソッドを利用するのが正しいのは言うまでもありません。 POST を使うときの経験則として、POST をリソースの新規作成にだけ使う、ことをいつも念頭におきましょう。

HTTP 状態コードの誤用

HTTP の状態コード(ステータスコード)は大切です。 200 とか 404 とか 500 とか 302 あたりが有名ですね。これらの番号を誤用すると、RESTful になりません。

たとえば、エラーが起きたときのことを考えましょう。クライアントのリクエストが悪いのに 500 を返す。あるいは逆にサーバが悪いのに 40X を返す。どちらも間違いです。

また、結果は明らかにエラーなのに、エラーメッセージを表示するために 200 を返すのも間違いです。あるいは、200 を返しながら、拡張 HTTP ヘッダで詳細コードを返す。どちらも RESTful でありません。

クッキーとセッション

REST アーキテクチャスタイルの重要な制約のひとつにステートレスがあります。ここでいうステートレスとは、クライアントとサーバの間の接続が状態を持っていないことを意味します。もう少し簡単にいうと、クライアントからサーバに送られるリクエストメッセージには、サーバがそのメッセージを処理するのに必要な情報がすべて含まれている、ということです。このようにアーキテクチャの制約としてステートレスを加えると、サーバ実装の簡略化とスケーラビリティの確保につながります。

しかし、現実の Web 実装ではそうでないものも多々ありますね。 HTTP をステートフルにする代表格はクッキーを使ったセッション管理です。 REST アーキテクチャスタイルの視点からみると、クッキーを使ったセッション管理は間違った HTTP の拡張、ということになります。

HTTP と URI を使うだけでは十分でない

今回の話題をまとめると、「HTTP と URI を使うだけでは十分でない」ということに尽きますね。いかに HTTP と URI を使って XML をやり取りしていても、間違った使い方であれば、それは REST アーキテクチャスタイルに従った実装ではありません。

次回は REST と SOAP の関係を、ほんの少しだけ説明しようと思います。

P.S. この weblog のタイトルを変更しました。

WWW2005

2005-05-09T23:28:00.000+09:00

今週金曜日、これを聞きに幕張まで行きます。どなたかこの日記を読んでいて、当日幕張に行きなおかつ REST architectural style に興味があって僕と情報交換してくれる日本語の通じる方は yoheiy at gmail dot com までご連絡ください :-)

ソーシャルブックマーク雑感

2005-05-07T22:30:00.000+09:00

REST 入門はちょっとお休みして、weblog っぽく日々の雑感でも。

僕は現在 del.icio.us とはてなブックマークを使ってます。この二つ、いちおう使い分けています。

del.icio.us: 自分用。主として英語ページのうち、わりと目に留まって読もうと思ったものをクリップ。その後読んだ後に感想を追加。後から検索する
はてなブックマーク: del.itio.us にポストしたもののうち、コメントがついたものをコピー。主として自分と同じ興味の人を探すため。今のところ見つけたのはたとえば hiromark さんとか

naoya さんのこのポストを読んで思ったのは、そういやカテゴリとかキーワードとかぜんぜん使ってないなーということ。僕もまさに **users しか使っていなかった。改めて自分のブックマークのカテゴリやキーワードを見てみると、特に英語系は厳しいですね。

僕自身としては、del.icio.us のタグは自分のためにつけています。あとで読み返して必要だったらタグを修正するし。昔ブックマークしたページを探すのもよくするんですが、その場合はタグを使うことが多い。で、うまくタグをつけないと見つからないので、苦労します。苦労して見つけたらタグを修正して次回から見つけやすくする。そんな風にしているので del.icio.us は自分にとっての財産となりつつあります。

はてなブックマークはあらかじめ日本語フィルタがかかっているのが大きいですね。自分と同じ興味の人は日本人が前提で考えているし、日本語記事のブックマーク率は del.icio.us よりも高い。注目のエントリーなんか暇つぶしにはもってこいだし。自分の日記の反響が見られるのもうれしい。

それから思うのははてなの財産は人だなということ。もちろん新しいサービスをどんどん作る中の人もだけど、それを受けて新しい使い方をどんどん考えてくれるユーザも含めて、財産(というか価値)なのでしょう。

ところで、はてなブックマークの注目のエントリーが 2ch のニュー速板のように見えるのは僕だけ？

REST 入門(その7) ハイパーメディアの可能性

2005-05-05T18:13:00.000+09:00

» REST 入門目次

前回は REST で受け渡しされるリソース同士が、 URI を使ったハイパーリンクで相互に結び付けられることによってハイパーメディアを実現し、その機能拡張には XML 名前空間などが利用できることを説明しました。

今回はより応用的なハイパーメディアと REST の関係を見ていきたいと思います。例によってはてなブックマークを使って説明します。

リソースの URI はひとつではない

現状のはてなブックマークでは、ひとつのブックマークエントリ(リソース)の URI は僕が知る限り以下の三つがあります。

ブックマーク一覧: http://b.hatena.ne.jp/yohei/20050429#187800
人間用 Edit URI: http://b.hatena.ne.jp/yohei/edit?eid=187800
Atom API 用 Edit URI: http://b.hatena.ne.jp/atom/edit/187800

このうち、一覧の URI は少し毛色が違いますが、人間用および Atom API 用 EditURI は同じリソースを指していると考えて問題ないでしょう。このようにひとつのリソースが URI を複数持つというのは珍しいことではありません。

同じリソースの別の URI にリンクしてみる

ただ、現状では人間用と Atom API 用がお互いに無関係なのが少しさみしいですね。以下のようにお互いの表現(representation)がリンクしていたらどうでしょうか。

人間用 http://b.hatena.ne.jp/yohei/edit?eid=187800

<html>
<head>
<title>はてなブックマーク - 傭兵ブックマーク</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link rel="stylesheet" type="text/css" href="/yohei/style" />
<link rel="service.edit" type="application/atom+xml" 
    title="ブックマークの編集"
    href="http://b.hatena.ne.jp/atom/edit/187800" />
</head>
<body>
...
</body>
</html>

Atom API 用 http://b.hatena.ne.jp/atom/edit/187800

<entry xmlns="http://purl.org/atom/ns#">
  <title>何はなくとも XML InfoSet: アウトプットの定義</title>
  <link rel="related" type="text/html" 
      href="http://luckypines.blogspot.com/2005/04/blog-post_28.html" />
  <link rel="alternate" type="text/html" 
      href="http://b.hatena.ne.jp/yohei/20050429#187800" />
  <link rel="alternate" type="text/html" 
      href="http://b.hatena.ne.jp/yohei/edit?eid=187800" />
  <link rel="service.edit" type="application/x.atom+xml" 
      href="http://b.hatena.ne.jp/atom/edit/187800" 
      title="何はなくとも XML InfoSet: アウトプットの定義" />
  <author>
    <name>yohei</name>
  </author>
  <generator url="http://b.hatena.ne.jp/" version="0.1"
    >Hatena::Bookmark</generator>
  <issued>2005-04-29T20:00:05+09:00
  <id>tag:hatena.ne.jp,2005:bookmark-yohei-187800</id>
  <summary type="text/plain"
    >一連の議論の中で一番共感しました。脳みそへのインターフェース</summary>
</entry>

URI の可搬性

リンクするとうれしいことはいろいろあると思うのですが、たとえば僕はこんなことを考えました。

はてなブックマークの専用クライアントがあるとします。ブックマークの編集操作をしたり、ブックマークエントリを他の blog にポストしたり、別のソーシャルブックマークサービスにコピーしたりする機能を持っています。ただ、そのままだと専用クライアントは通常あまり使いません。なぜかというと Web を閲覧するのは Web ブラウザでするし、ブックマークするのも bookmarklet でできるからです。専用クライアントを使うのはせいぜいブックマークの大量削除などのときくらいでしょう。

しかし、たとえばこんな使い方ができたらどうでしょうか。ブラウザと同じように、専用クライアントも URI 欄(アドレス欄)を持っているとします。ブラウザで表示しているはてなブックマークの URI をコピーして専用クライアントに貼り付けられます。すると、その URI で特定されるブックマークエントリに対して、その専用クライアントで可能な操作が一覧される。あるいはあらかじめ操作を選んでおいて、 URI を貼り付けるとはてなブックマークのエントリが del.icio.us と spurl に自動的にコピーされる。

ブックマークエントリリソースの表現が相互にリンクされていれば、このプログラムの実装は簡単です。専用クライアントは渡された URI を HTTP GET します。返ってくる内容の Content-Type が text/html であれば、 /html/head/link[@rel="service.edit"]/@href を検索し(こんなの XPath で一発ですね) EditURI を GET すればプログラムで扱いやすい XML 形式のリソースの表現が取得できるからです。あとは、得られた情報を適切に操作するだけです。

URI のコピーアンドペーストは最も原始的なリンクだといえます。手作業でのコピペはダサいんですが、これを自動化するのは簡単でしょう。専用クライアントがブラウザの拡張プログラムであれば、リンク選択時の右クリックメニューに「専用プログラムへ渡す」という項目を追加するだけです。この機能はハイパーリンクに他なりません。

このように、 URI だけでアプリケーション連携を実現できるのが REST(WWW) アーキテクチャスタイルの素晴らしい点です。これはいわゆる疎結合(loosely-coupled)という性質です。

コンテントネゴシエーションによるソリューション

前節の URI コピペの実装には別の方法もあります。 HTTP のコンテントネゴシエーションを使う方法です。これは同じ URI でも、クライアントが指定した Content-Type のリソース表現を返すというものです。

例を見てみましょう。専用クライアントは、人間用 URI に以下のリクエストを発行します。

GET /yohei/edit?eid=187800 HTTP/1.1
Host: b.hatena.ne.jp
Accept: application/x.atom+xml; q=1.0, text/html; q=0.8, */*; q=0.1

サーバは Accept ヘッダを解析することで、クライアントが必要としているのが HTML よりも Atom 形式であることがわかります。

このように実装してあると、ブラウザで表示している URI と専用クライアントが操作する URI がまったく同じになります。ただし、クライアント側の選択で、転送されるリソースの表現が HTML になったり、Atom になったりします。

XHTML によるソリューション

実はさらに別の方法も考えられるのです。それはブックマークリソースが返す表現を XHTML にして、 head 要素の中に Atom の XML を丸ごと入れてしまう方法です。このようにすれば、そもそも表現自体をクライアントごとに分ける必要もなく、ただひとつの URI で済ませることができるでしょう。

まとめと課題

これまで見てきたように、URI と HTTP を組み合わせたハイパーメディアにはいろいろな可能性がありそうです。さらに XML/XHTML を組み合われば、ブラウザとそれ以外の専用アプリ(あるいはブラウザの拡張)が自由に連携できそうです。

しかし、現実はそれほど甘くありません。きちんと REST アーキテクチャスタイルの制約に従ったアーキテクチャの Web アプリケーションであれば、あまり問題なく XML を使った RESTful な Web サービスを提供できるでしょう。しかし世の中にはそうでない Web アプリケーション実装が多いのも事実です。

次回は REST アーキテクチャスタイルに反する Web の実装を見ていこうと思います(連休中に書ききれるかと思ったけど無理っぽいなー)。

REST 入門(その6) ハイパーリンクと XML

2005-05-05T00:47:00.000+09:00

» REST 入門目次

前回、はてなブックマークを例にリソースと四つの HTTP メソッド (GET, POST, PUT, DELETE) の関係について解説しました。今回は、リソース同士をどのように関連付けるか、について解説します。

前回の記事でこんな疑問を持った人はいなかったでしょうか。

ひとつのブックマークリソースにいろいろなメソッドを適用しているけれど、そのブックマークリソースにはいったいどうやってたどり着くのか。

たとえば PostURI に POST して新規作成したブックマークを全部覚えておけば、それぞれのリソースの URI はわかります。しかしそれではソーシャルブックマークサービスを使う意味がありません。ローカルディスクまたはローカルサーバに保存しておくのではブックマークを共有することができないし、そもそも自分以外の人のブックマークにアクセスできないのでは、ソーシャルブックマークとは言えません。残念ながら、現状のはてなブックマーク AtomAPI は、以下の操作しか提供されていません。

新規ブックマークの投稿 (PostURI への POST)

投稿したブックマークのタイトル、コメントの変更 (EditURI への PUT)

投稿したブックマークの削除 (EditURI への DELETE)

投稿したブックマークの参照 (EditURI への GET)

最近投稿したブックマークの一覧の取得 (FeedURI への GET)

他のユーザのブックマークを閲覧することもできないし、そもそも自分が登録したブックマークの一覧を全部取得することもできません。

はてなブックマーク AtomAPI はまだ発展途上のサービスなので、機能不足なのは仕方ありませんが、 REST とハイパーメディアの関係を語るにはちょっとさみしいのも事実です。以下では、はてなブックマーク AtomAPI にない機能を独自に拡張しながら、 REST とハイパーメディア、それから XML の関係を解説します。

リソースの関連付け -- ハイパーリンク

REST ではリソース同士の関係をハイパーリンクで記述します。たとえば、自分が「最近登録したブックマークのリスト」というリソースの URI は

http://b.hatena.ne.jp/atom/feed

になります。この URI を GET してみましょう。

GET /atom/feed HTTP/1.1
Host: b.hatena.ne.jp
X-WSSE: UsernameToken Username="yohei",...

HTTP/1.1 200 OK
Content-Type: application/x.atom+xml

<feed version="0.3" 
      xmlns="http://purl.org/atom/ns#"
      xml:lang="ja">
  <title>傭兵ブックマーク</title>
  <link rel="alternate" type="text/html" href="http://b.hatena.ne.jp/yohei/" />
  <link rel="service.post" type="application/x.atom+xml"
      href="http://b.hatena.ne.jp/atom/post" title="傭兵ブックマーク" />
  <modified>2005-04-29T21:43:51+09:00</modified>
  <author>
    <name>yohei</name>
  </author>
  <id>tag:hatena.ne.jp,2005:bookmark-yohei</id>
  <generator url="http://b.hatena.ne.jp/" version="0.1">Hatena::Bookmark</generator>
  
  <entry>
    <title>何はなくとも XML InfoSet: アウトプットの定義</title>
    <link rel="related" type="text/html"
        href="http://luckypines.blogspot.com/2005/04/blog-post_28.html" />
    <link rel="alternate" type="text/html"
        href="http://b.hatena.ne.jp/yohei/20050429#187800" />
    <link rel="service.edit" type="application/x.atom+xml"
        href="http://b.hatena.ne.jp/atom/edit/187800"
        title="何はなくとも XML InfoSet: アウトプットの定義" />
    <issued>2005-04-29T20:00:05+09:00
    <author>
      <name>yohei</name>
    </author>
    <id>tag:hatena.ne.jp,2005:bookmark-yohei-187800</id>
    <summary type="text/plain"
      >一連の議論の中で一番共感しました。脳みそへのインターフェース</summary>
  </entry>
...
</feed>

レスポンスは Atom で定義されるいわゆる Atom フィードになります。このフィードには最近登録したブックマークが 20 件入っています。フィードに含まれるそれぞれのエントリには link 要素によって表現されるハイパーリンクがいくつか含まれます。

もっとも重要なリンクは EditURI へのリンクです。

<link rel="service.edit" type="application/x.atom+xml"
    href="http://b.hatena.ne.jp/atom/edit/187800"
    title="何はなくとも XML InfoSet: アウトプットの定義" />

前回、いろいろと操作したブックマークリソースの URI がこの EditURI になります。

その他にもリンクがあります。一つ目は、このブックマークのターゲット、ブックマークした Web ページへのリンクです。

<link rel="related" type="text/html"
    href="http://luckypines.blogspot.com/2005/04/blog-post_28.html" />

もうひとつは、このブックマークリソースの HTML 表現、つまり人間用の Web ページへのリンクです。

<link rel="alternate" type="text/html"
    href="http://b.hatena.ne.jp/yohei/20050429#187800" />

それぞれのリンクは、別のリソースの URI を指定していますので、リソースに HTTP メソッドを適用することができます。どの HTTP メソッドを適用できるかは仕様しだいです。たとえば EditURI であれば、GET/PUT/DELETE が適用できることが、明記されています。

過去のブックマークの取得

前節で解説した FeedURI は現状のはてなブックマーク AtomAPI でサポートされている機能です。しかし、現在のフィードの実装では最新の20件しか取得することができません。それ以前のブックマークを取得する方法を検討してみましょう。

この目的を達成するにはいくつかの方法が考えられると思いますが、今回は検索インターフェースをつける方法をご紹介します。

ここで登場するリソースは、「検索結果」リソースです。検索結果リソースはこれまでみてきたリソースとは少し趣が異なります。たとえばキーワード "REST" を検索した検索結果の URI は以下のようになります。

http://b.hatena.ne.jp/atom/search?q=REST

また、キーワード "XML" を検索した検索結果の URI は以下のようになります。

http://b.hatena.ne.jp/atom/search?q=XML

サンプルで明らかだと思いますが、重要なのは URI の "?q=" の部分です。これは問合せ文字列(query string)と呼びます。通常 URI はクライアントで構築することはありませんが、この問合せ文字列だけはクライアント側で操作することができます。その結果生成された URI はそのキーワードの検索結果の URI を示します。

空文字列のキーワードも許可するように実装すれば、これまで自分が登録したブックマークをすべて含む検索結果のリソースを特定する URI を作ることもできます。

多くの場合、検索結果は膨大な件数になります。そのため結果を複数に分けるいわゆるページング処理が必要となります。分割された結果一つ一つがそれぞれリソースとなります。 21番目の結果から20件を表現するリソースの URI はたとえば以下のようになります。

http://b.hatena.ne.jp/atom/search?q=REST&start=21&num=20

同様の情報を検索結果リソース自身にも入れましょう。 XML 名前空間を使えば、標準以外の情報を Atom フィードに組み込むのは簡単です。都合のよいことに、OpenSearch RSS という規格で、この用途にぴったりのタグを規定してくれています。

GET /atom/search?q=REST&start=1&num=20 HTTP/1.1
Host: b.hatena.ne.jp
X-WSSE: UsernameToken Username="yohei",...

HTTP/1.1 200 OK
Content-Type: application/x.atom+xml

<feed version="0.3" 
      xmlns="http://purl.org/atom/ns#"
      xmlns:openSearch="http://a9.com/-/spec/opensearchrss/1.0/"
      xml:lang="ja">
  <title>傭兵ブックマーク</title>
  <link rel="alternate" type="text/html" href="http://b.hatena.ne.jp/yohei/" />
  <link rel="service.post" type="application/x.atom+xml"
      href="http://b.hatena.ne.jp/atom/post" title="傭兵ブックマーク" />
  <modified>2005-04-29T21:43:51+09:00</modified>
  <author>
    <name>yohei</name>
  </author>
  <id>tag:hatena.ne.jp,2005:bookmark-yohei</id>
  <generator url="http://b.hatena.ne.jp/" version="0.1">Hatena::Bookmark</generator>
  <openSearch:totalResults>24</openSearch:totalResults>
  <openSearch:startIndex>1</openSearch:startIndex>
  <openSearch:itemsPerPage>20</openSearch:itemsPerPage>
...
<:/feed>

あまり詳しく説明しませんが、この検索結果は24件あって、そのうちここでは1番から20件分を表示している、ということになります。 21番から24番までの検索結果のリソースへのリンクをつけてもよいのですが、 openSearch には適当なタグがなかったのでしていません。とりあえずクライアント側で問合せ文字列を構築することで対応できます。

なんだか長くなってしまったので、今回はここまで。次回も続けて、今度はもっと応用的な REST におけるハイパーリンクとハイパーメディアの可能性について解説したいと思います。

REST 入門(その5) 四つの動詞 -- GET, POST, PUT, DELETE

2005-04-29T14:48:00.000+09:00

» REST 入門目次

前回、URI で特定できるリソースに HTTP の GET という動詞を適用して、ある時点・条件での状態の表現を転送するのが REST だという説明をしました。 URI (名詞)に適用できる動詞は GET だけではありません。

今回は GET 以外の三つの動詞を紹介します。

前提知識

ここでは実際に稼動している REST 実装の例としてはてなブックマーク AtomAPI を使います。はてなブックマークそのものの説明はしませんので、あらかじめご了承ください。

はてなブックマークに登録したひとつのブックマークを考えてみてください。このひとつのブックマークエントリが、対象のリソースになります。たとえば REST 入門の目次をブックマークしたとします。このブックマークの URI は http://b.hatena.ne.jp/atom/edit/175062 です。まずは GET してみましょう。

GET /atom/edit/175062 HTTP/1.1
Host: b.hatena.ne.jp
X-WSSE: UsernameToken Username="yohei", ...

HTTP/1.1 200 OK
Content-Type: application/x.atom+xml

<entry xmlns="http://purl.org/atom/ns#">
  <title>傭兵日記: REST 入門</title>
  <link rel="related" type="text/html"
      href="http://yohei-y.blogspot.com/2005/04/rest_23.html" />
  <link rel="alternate" type="text/html"
      href="http://b.hatena.ne.jp/yohei/20050424#175062" />
  <link rel="service.edit" type="application/x.atom+xml"
    href="http://b.hatena.ne.jp/atom/edit/175062" title="傭兵日記: REST 入門" />
  <author>
    <name>yohei</name>
  </author>
  <generator url="http://b.hatena.ne.jp/" version="0.1"
    >Hatena::Bookmark</generator>
  <issued>2005-04-24T:14:46:00+9:00</issued>
  <id>tag:hatena.ne.jp,2005:bookmark-sample-175062</id>
  <summary type="text/plain">REST の入門</summary>
</entry>

実際にはてなブックマークから GET するには認証用の X-WSSE ヘッダが必要なことに注意してください。また、レスポンスに含まれるのは HTML ではなく XML 形式のブックマークとなります。 XML に含まれる情報で重要なのは title 要素と summary 要素になります。 summary 要素はいわゆる「コメント」です。

以下では、このブックマークエントリ(リソース)の URI に、 GET 以外の HTTP メソッドを適用してみます。

リソースを更新 -- PUT

一度は登録したけれど、つけたコメントが気に入らないので修正したいとします。こんなときは HTTP の PUT メソッドを使います。PUT リクエストはこのようになります。

PUT /atom/edit/175062 HTTP/1.1
Host: b.hatena.ne.jp
Content-Type: application/x.atom+xml
X-WSSE: UsernameToken Username="yohei", ...

<entry xmlns="http://purl.org/atom/ns#">
  <summary type="text/plain"
    >REST(Representational State Transfer) の入門</summary>
</entry>

PUT のレスポンスはこのようになります。

HTTP/1.1 200 OK

今、更新した URI を再度 GET することができます。

GET /atom/edit/175062 HTTP/1.1
Host: b.hatena.ne.jp
X-WSSE: UsernameToken Username="yohei", ...

取得される XML は、コメントが修正されたものになっているはずです。

HTTP/1.1 200 OK
Content-Type: application/x.atom+xml

<entry xmlns="http://purl.org/atom/ns#">
  <title>傭兵日記: REST 入門</title>
  <link rel="related" type="text/html"
      href="http://yohei-y.blogspot.com/2005/04/rest_23.html" />
  <link rel="alternate" type="text/html"
      href="http://b.hatena.ne.jp/yohei/20050424#175062" />
  <link rel="service.edit" type="application/x.atom+xml"
    href="http://b.hatena.ne.jp/atom/edit/175062" title="傭兵日記: REST 入門" />
  <author>
    <name>yohei</name>
  </author>
  <generator url="http://b.hatena.ne.jp/" version="0.1"
    >Hatena::Bookmark</generator>
  <issued>2005-04-24T:14:46:00+9:00</issued>
  <id>tag:hatena.ne.jp,2005:bookmark-sample-175062</id>
  <summary type="text/plain"
    >REST(Representational State Transfer) の入門</summary>
</entry>

リソースを削除 -- DELETE

ブックマークを削除したい場合は DELETE メソッドを使います。

DELETE /atom/edit/175062 HTTP/1.1
Host: b.hatena.ne.jp
X-WSSE: UsernameToken Username="yohei", ...

HTTP/1.1 200 OK

DELETE が成功すると、同じ URI を再度 GET することはできません。

GET /atom/edit/175062 HTTP/1.1
Host: b.hatena.ne.jp
X-WSSE: UsernameToken Username="yohei", ...

レスポンスは HTTP エラーになります。

HTTP/1.1 404 Not Found

リソースを新規作成 -- POST

先ほどのブックマーク、消してしまったけれどやっぱり元に戻したいとします。そんなときは POST でブックマークリソースを新規に作成します。でも、どの URI に POST したらよいのでしょうか。リソースを新規に作成するわけですから、リソース自体がまだ存在せず、したがって URI もありません。

こういう時はリソースを新規作成するためのリソースを用意します。はてなブックマークではこのリソースの URI を PostURI と呼んでいます。それでは POST してみましょう。

POST /atom/post HTTP/1.1
Host: b.hatena.ne.jp
X-WSSE: UsernameToken Username="yohei", ...

<entry xmlns="http://purl.org/atom/ns#">
  <link rel="related" type="text/html"
      href="http://yohei-y.blogspot.com/2005/04/rest_23.html" />
  <summary type="text/plain"
    >REST(Representational State Transfer) の入門</summary>
</entry>

正常に受け付けられると以下のようなレスポンスが返ってきます。

HTTP/1.1 201 OK
Content-Type: application/x.atom+xml
Location: http://b.hatena.ne.jp/atom/edit/xxxx

<entry xmlns="http://purl.org/atom/ns#">
  <title>傭兵日記: REST 入門</title>
  <link rel="related" type="text/html"
      href="http://yohei-y.blogspot.com/2005/04/rest_23.html" />
  <link rel="alternate" type="text/html"
      href="http://b.hatena.ne.jp/yohei/20050424#xxxx" />
  <link rel="service.edit" type="application/x.atom+xml"
    href="http://b.hatena.ne.jp/atom/edit/xxxx" title="傭兵日記: REST 入門" />
  <author>
    <name>yohei</name>
  </author>
  <generator url="http://b.hatena.ne.jp/" version="0.1"
    >Hatena::Bookmark</generator>
  <issued>2005-04-24T:17:46:00+9:00</issued>
  <id>tag:hatena.ne.jp,2005:bookmark-sample-xxxx</id>
  <summary type="text/plain"
    >REST(Representational State Transfer) の入門</summary>
</entry>

レスポンスには Location ヘッダがあります。これが新規作成されたリソースの URI になります。

POST メソッドは、その自由度の高さから、濫用される傾向にあります。実際には GET, PUT, DELETE で行えることも、POST でできてしまうのです。しかし、HTTP メソッド本来の意味を考えて POST メソッドを利用するのが正しいのは言うまでもありません。 POST を使うときの経験則として、POST をリソースの新規作成にだけ使う、というものがあります。新しいリソースを POST する、と覚えましょう。 Paul Prescod の "Common REST Mistakes" の2番がこれに該当します。

まとめ

今回の POST, PUT, DELETE と、前回の GET はある点で大きく異なります。それは GET がリソースの状態に影響を与えないのに対して、それ以外の三つの動詞がリソースの状態に何らかの影響を与える可能性がある点です。このような性質を副作用(side effect)といいます。副作用のない GET はキャッシュという大きな可能性を持つことになります。キャッシュについては機会があれば説明しようと思います。

これまでの内容をまとめると以下のようになります。

GET はリソースを取得するメソッド
PUT はリソースを更新するメソッド
DELETE はリソースを削除するメソッド
POST はリソースを新規作成するメソッド
GET はリソースに副作用を与えない

REST では、リソースを操作するインターフェースにはこの四つのメソッドしかありません。 getXx() も setXx() も startXx() も createXx() もないのです。これは REST アーキテクチャスタイルの持つ大きな制約のひとつ、統一インターフェース(uniform interface)です。

次回は、Web の最大の特徴であるリンクと REST の関係について解説したいと思います。

[update 2005-05-22] POST と PUT についての記事を追加しました。

[update 2007-09-21] 2007年7月に Atom Publishing Protocol は標準化作業が終了しました。また、その技術解説を WEB+DB PRESS Vol.40 に書いています。

REST 入門(補足) アーキテクチャとアーキテクチャスタイル

2005-04-27T20:40:00.000+09:00

» REST 入門目次

僕の説明だと、どうもアーキテクチャとアーキテクチャスタイルについて混乱を招きそうなので、補足しておきます。デザインとデザインパターンが違うように、アーキテクチャとアーキテクチャスタイルは別物です。デザインパターンの本といえば GoF とか結城さんの2冊が有名ですね。デザパタ本に載っているのはデザインそのものではなくデザインのパターンです(ムズカシイ?)。

つまりこういうことです。僕たちは結城さんの本でデザインパターンを勉強します。デザインパターンはある問題領域においての経験則的なクラス設計の指針、作法、流儀です。あの本自体に自分のプログラムのデザイン(設計)が書いてあるわけではありません。本に書いてあるパターンを学習して、そのパターンを自分自身のプログラムのデザインに適用します。デザインというのは本に書いてあるのではなく、僕たちが実際に作るプログラムにおいて初めて具現化されるものなのです。

アーキテクチャスタイルも同様です。現実の世界で作られる実際のシステムはアーキテクチャを持っています。そのアーキテクチャを設計するときに、ただ闇雲にものを作っていくのではなく、世の中にすでにたくさんあるアーキテクチャ設計の指針、作法、流儀を適用するはずです。そのほうが作業効率がいいし、先人の知恵を活用することできちんと動くものが作れるから。

でも、実際は忙しかったり、納期が迫っていたり、調べるのが面倒だったり、とにかく作らなければならなかったり、あるいは単に無知だったりして、アーキテクチャスタイルを適用しない(できない)こともあります。すると、いちおう動くんだけどちょっと変なシステムや、最悪だとパフォーマンスやセキュリティに重大な欠陥を抱えたシステムができたりします。

REST の実装は Web だといいましたが、 REST じゃない実装の Web もあります。後ほど詳しく説明する予定ですが、たとえば Cookie、たとえば URI へのアクション埋め込み、キャッシュを無視した POST の濫用、などはすべてアーキテクチャスタイルとしての REST を無視したか、あるいは知らないために起きている問題です。

本題がちとずれました。元の話(アーキテクチャとアーキテクチャスタイル)に戻ります。アーキテクチャはあなた自身のシステムのものです。それを作るときに、アーキテクチャスタイルを適用しましょう。

REST 入門(その4) HTTP GET -- その絶大な効果

2005-04-24T13:14:00.000+09:00

» REST 入門目次

前回は、リソースの特徴について解説しました。しかし、なぜリソースが重要なのかはまだわからないと思います。今回はその一部を紹介します。

まず、おさらいしましょう。僕たちは以下のリソースを例に使っています。

東京の天気予報
2005年8月24日のスケジュール
新花巻駅の写真
Dijkstra 著 "Go To Statement Considered Harmful"
僕の最近のブックマーク

そして、それぞれのリソースの識別子(URI)は以下のようになります。

http://weather.yahoo.co.jp/weather/jp/13/4410.html
https://example.com/schedule/20050824
http://www.flickr.com/photos/60043209@N00/6337155/
http://www.acm.org/classics/oct95/
http://del.icio.us/yohei

ここで質問です。URI を与えられたら、あなたは何をしますか?

ここで答を直接聞けないのは残念ですが、大多数の人は、URI をコピーして Web ブラウザの URI 欄(IEだったらアドレス欄)に貼り付け、そしてリターンキーか「移動」ボタンを押すのではないでしょうか。上記の URI は、スケジュール以外は全部実際にブラウザで見ることができるURL ばかりです。ぜひコピー&ペーストしてみてください。

URL 貼り付けというなにげない日常的な行為、これが REST では非常に重要なのです。ブラウザに URI を入力してリターン、するとブラウザはURI に示された Web サーバに対して HTTP の GET メソッドを発行します。

GET /weather/jp/13/4410.html HTTP/1.1
Host: weather.yahoo.co.jp

Web サーバは結果(その時点での東京の天気予報の HTML ページ)をブラウザに返します。

HTTP/1.1 200 OK
Content-Type: text/html; charset=euc-jp

実際の HTML がここに入る

世界中の人々が日々行っているこのなにげない作業を REST 流に説明すると、名詞(リソース)に動詞(HTTP GET)を適用した、ことになります。

ナンジャソリャ? と思った人もいるかもしれませんが、これはいわゆる「抽象化」です。現実の世界で起きている Yahoo の東京の天気予報のページをブラウザに表示する、という行為から個別の事情を取り払い、なるべく汎用的に使える言葉で説明する(抽象化する)と「Yahooの東京の天気予報」というリソースを取得(ゲット、GET、HTTP で GET)する(取得する」という動詞を適用)、となるのです。

この HTTP GET という抽象化は絶大な効力を発揮しています。あるリソースを識別する URI さえ与えられれば、ブラウザを使って HTTP GET を適用するだけで、そのリソースのある時点での表現を取得できるのです。それが HTML 文書だろうと、PNG 画像だろうと、.swf ファイルだろうと、Javascript だろうと関係ありません。

ここで「リソースのある時点での表現」という言葉が出てきました。これは REST の名前の元になっている Representational state のことです。 Representational state とは、あるリソースのある時点・条件での状態の表現を指します。今日の時点での天気予報リソースと明日の時点での天気予報リソースは、リソース自体の状態が異なるので取得できる表現も違います。また、その表現は HTML かもしれないし、XML かもしれないし、PDF かもしれないし、はたまた何か別の形式かもしれません。この表現をネットワークを介して転送する(Transfer)のが Representational State Transfer (REST) です。

今回はここで終了です。次回は GET 以外の動詞を見ていこうと思います。

REST 入門(その3) 全てはリソースから

2005-04-23T19:38:00.000+09:00

» REST 入門目次

では(やっと) REST の具体例を見ていきましょう。

REST で最も重要な概念はリソースです。以下にリソースの具体例を挙げてみます。

東京の天気予報
2005年8月24日のスケジュール
新花巻駅の写真
Dijkstra 著 "Go To Statement Considered Harmful"
僕の最近のブックマーク

REST においてリソースとは名前のつくあらゆる情報を指します(つまり名詞ですね)。たとえば、「東京の天気予報」というリソースには今日の天気予報も明日の天気予報も含まれるでしょう。あるいは「2005年8月24日のスケジュール」には僕のスケジュールだけでなく、あなたのスケジュールも含まれるかもしれません。リソースで重要なのは、その意味です。リソースの実体は時間や条件によって変化するかもしれませんが、その意味は不変です(これが名詞たる所以)。

上記のリソースの例を再度見てください。これらは WWW (= REST の実装) 上に存在するものばかりです。

「東京の天気予報」は Yahoo Japan の東京地方の天気予報のページ
「2005年8月24日のスケジュール」は会社のグループウェアのスケジュール
「新花巻駅の写真」は Flickr に登録した東北旅行のときの一枚の写真
「Dijkstra 著 "Go To Statement Considered Harmful"」はこのページ
「僕の最近のブックマーク」はソーシャルブックマークサイト del.icio.us のページ

といったぐあいです。

全てのリソースは識別子を持ちます。 Web の識別子といえば、URI (Uniform Resource Identifier) ですね。もう一度サンプルを見てください。

それぞれの URI は以下のようになります。

http://weather.yahoo.co.jp/weather/jp/13/4410.html
https://example.com/schedule/20050824
http://www.flickr.com/photos/60043209@N00/6337155/
http://www.acm.org/classics/oct95/
http://del.icio.us/yohei

ここで、リソースの特徴を考察してみます。上記の例のとおり、リソースは URI で識別される情報です。 URI で識別される情報は、時間や条件によって内容が変化する可能性があります。たとえば、今日見る天気予報と明日見る天気予報では、含まれる内容は異ります。しかし、両者とも東京の天気予報であることにはかわりありません。今、リソースの内容と書きましたが、その内容は取得する時点でのリソースの状態(state)で決まります。天気予報というリソースは、時間の経過と共に状態が変化していくと考えるとわかりやすいと思います。もちろん状態が変化しないリソースもあります。ダイクストラのレターの状態が変化する可能性はもうないですよね。

ここまでで、REST におけるリソースの特徴をまとめると以下のようになります。

全ての情報はリソース
リソースは識別子(URI)を持つ
リソースの状態は時間や条件とともに変化する可能性がある
リソースの意味は時間や条件が変化しても不変である

このリソースが、REST では非常に重要になります。その秘密は、次回以降で説明します。

REST 入門(その2) アーキテクチャスタイルとは?

2005-04-23T12:31:00.000+09:00

» REST 入門目次

REST そのものを説明する前に、まずアーキテクチャスタイルとは何なのかを解説します。

アーキテクチャスタイル(英文では architectural style です) は別名(マクロ)アーキテクチャパターンともいい、複数のアーキテクチャに共通する性質、様式、作法あるいは流儀を指す言葉です。パターンという言葉からデザインパターンを想像する人も多いかもしれませんが、いわゆるデザインパターンは別名マイクロアーキテクチャパターンといい、アーキテクチャスタイルよりも粒度の細かいクラスなどの設計様式を指します。

具体例を挙げましょう。
たとえば MVC (Model View Controler) はアーキテクチャスタイルの一種です。他にパイプ&フィルタ、インタプリタ、イベントシステムなどもアーキテクチャスタイルになります。

REST は数あるアーキテクチャスタイルの中でも特にネットワークシステムのアーキテクチャスタイルになります。ネットワークシステムのアーキテクチャスタイルとして最も有名なのはみなさんご存知のクライアントサーバです。サーバとクライアントが線で結び付いている絵を思い浮べてください。

クライアントサーバと聞いて「あれれ」と思った人がいるかもしれませんね。「はじめに」で REST は Web のアーキテクチャスタイルだと言いました。しかし、Web はクライアントサーバでもあります。これはいったいどういうことでしょうか。

実は REST はクライアントサーバから派生したアーキテクチャスタイルなのです。素のクライアントサーバアーキテクチャスタイルにいくつかの制約を加えていくと、 REST アーキテクチャスタイルになります。この「制約」というのはアーキテクチャスタイルにおいて重要な概念です。一般にソフトウェアアーキテクチャは複数のコンポーネントを組み合わせて実現しますが、それぞれのコンポーネントがバラバラに動いているのでは動作しません。そこで、各コンポーネントに制約を課していきます。その結果、全体として各コンポーネントが協調して動作するようになります。

クライアントサーバから REST に至る過程で加えられた制約には、たとばステートレスやキャッシュなどがあります。

最後に、アーキテクチャスタイルとは特定の実装を指すものではないことに注意してください。 WWW は REST の一実装形態です。WWW 以外の REST の実装も考えられます。しかし、現実には REST といえば WWW のアーキテクチャスタイルを指す場合が多いので、これからは特にことわりなく REST の実装例として WWW を使っていきます。

次はやっと REST そのものについて記述します(長いなー)。

[update 2005-04-27 アーキテクチャとアーキテクチャスタイルについて補足を追加しました。]

REST 入門(その1) はじめに

2005-04-23T12:17:00.000+09:00

» REST 入門目次

REST は Apache 創始者のひとりであるロイ・フィールディングさんが、彼の博士論文で提唱したネットワーク分散システム、特に WWW のアーキテクチャスタイルです。 WWW 技術はなぜ成功したのか、その特徴は何なのか、ということについてソフトウェアアーキテクチャの観点から見直し、そのあるべき姿について論じるための基礎的な資料となるものです。

REST は既存の Web アプリケーション(人間が使うサービス)だけではなく、いわゆる Web サービス(機械が使えるサービス)のためのアーキテクチャスタイルでもあります。いわゆる SOAP を使った Web サービスとはアーキテクチャが真っ向から対立するため、 REST と SOAP はしばしば対立軸で語られます。

残念なことに、日本ではアーキテクチャスタイルとしての REST はあまり論じられてこなかったように筆者は感じています(間違いだったらゴメンナサイ)。そのため単なる XML ベースの API としての REST のみが注目されているのが現状です。

しかしながら Web アプリケーションや Web サービスを構築するときに、アーキテクチャスタイルとしての REST に関する知識があるとスケーラビリティやユーザビリティが向上するはずです。もしあなたが CORBA や DCOM を知っているなら、REST とのアーキテクチャの違いが興味深いかもしれません。もしあなたが XML guy なら :-) REST は XML の王道だと感じるかもしれません。

これからの一連のポストは、ある程度の専門知識を前提として記述します。ソフトウェア工学やネットワークに関する基礎知識があることが望ましいです。また、サンプルを理解するために HTTP, URI, XML の基礎知識が必用です。

次の記事では、まずアーキテクチャスタイルとは何なのかを解説します。

REST 入門

2005-04-23T12:14:00.001+09:00

日本語の REST のリソース集を以前作ったのだが、日本語では一般人向けの解説がない。 sheepman 氏の REST のページはすばらしいんだけど、多少わかっている人向けだ。市山氏のプレゼン資料は RoyF の論文を詳しく解説していてよいのだけれど、いかんせんアカデミックすぎる。技術的な要素も抑えつつ、入門者にもわかりやすい解説はないものかと探していたのだが、みつからない。英語の文書を訳すことも考えたんだけど、あまりよいものが見つからない。
で、結局自分で書くことにした。
最初はひとつのポストで済ませるつもりだったんだけど、書き始めたら長くなってしまったので、複数のポストに分けることにした。えらそうなことを書いたが、内容は「ないよりマシ」といったレベルだろう。
前書きが長くなったけど(ここから始まりです。ですます調なのは入門記事だから)、この記事(から始まる一連のポスト)は Representational State Transfer (REST) の日本語での紹介です。僕(yohei)自身、REST を完全に理解しているわけではありませんので、間違いやコメントなどを yoheiy at gmail dot com まで頂ければと思います。もちろん、この日記のコメントでご指摘頂いても構いません。
このポストは目次用です。新しい記事がポストされたら随時変更します。一連の記事のインデックスページとしてご利用ください。

はじめに
アーキテクチャスタイルとは
全てはリソースから
HTTP GET -- その絶大な効果(IE で画面が真っ白になる場合はメニューの表示→エンコード→Unicode(UTF-8) を選んでください)
四つの動詞 -- GET, POST, PUT, DELETE
ハイパーリンクと XML
ハイパーメディアの可能性
REST でないもの
REST と SOAP
終わりに

ではまず「はじめに」から
以下は追記です(2007-09-21)。その後、Web 上でいろいろと REST に関する記事を書いたり、雑誌に連載をしたりしています。

WEB+DB PRESS Vol. 32 に REST 入門という記事を書きました
第八回XML開発者の日はREST特集でした
WEB+DB PRESS Vol. 38 から REST に関する連載を行っています

さらに追記(2010-04-08) このエントリを拡張してさらに詳しくRESTについて書いた本を書きました。こちらもぜひご参照ください。

Webを支える技術 ── HTTP、URI、HTML、そしてREST: 山本陽平; 技術評論社 2010-04-08

yohei-y:weblog

Webを支える技術ジュンク堂トークセッション（第4回卓人の部屋）総括

『Webを支える技術 ── HTTP、URI、HTML、そしてREST』という本を書きました

yokohama.pm で Eventually Consistent の話をしてきました

CAPのCとACIDのC

CAP と BASE について調べたこと

RESTレシピ ―― クールなWebシステムへの道しるべ【最終回】リソースモデリング

半構造データ、あるいは Web 上のデータ

個人的なバックグランド

Web との出会い

NAIST へ

XML への熱い期待

XML を使う

Web とデータベースとデータベース管理システム

データの天動説

Data on the Web と半構造データ

連載読んでても楽しめた。子飼弾のアルファギークに逢ってきた

RESTful Web サービスの読みどころ: 4章 リソース指向アーキテクチャ(ROA)

RESTful Web サービスTシャツプレゼント企画

RESTful Web サービスの読みどころ: 3章 RESTfulサービスの特徴

RESTful Web サービスの読みどころ: 2章 Web サービスクライアントの作成

WEB+DB PRESS Vol.42 と7周年記念イベント

RESTful Web サービスの読みどころ: 1章プログラマブルWebとWebサービス

RESTful Web サービスの読みどころ: はじめに

第10回XML開発者の日

ステートレスとは何か

AtomPub が RFC 5023 に/日本語訳を公開します

REST の勝利宣言と良い XML の見分け方

いろいろ改め AtomPub の話と、パターンの話と、消費電力の話と、古くて新しい開発環境の話と、Tim Bray のインタビューと、Dave Thomas のTシャツプレゼントが載ってる WEB+DB PRESS Vol.40

APP の標準化作業がほぼ終了

APP Interop in Tokyo

[これはすばらしい] mixi ステーション API。ただ一つ注文が…

HTTP ステータスコードを正しく使おう

Restful Web Services

WEB+DB PRESS Vol. 38

Dr. Jim Gray がヨットで行方不明に

S はシンプルの S

[図解]東京の地下技術

第九回XML開発者の日 終了

第九回XML開発者の日

REST 本

Webサービスプラットフォームアーキテクチャ

WEB+DB PRESS Vol.34

XML の本当のメリットは拡張性を保証して構造化文書もマークアップできること

The Atom Publishing Protocol as Universal Web Glue

APP as universal web glue

本3冊

次の話

日経SYSTEMS。

WEB+DB PRESS Vol.32 に REST の記事を書きました

Shibuya.js 行ってきた ($X 最高)

カミングアウト。

REST ってやっぱり難しいかも。

REST は難しい、だからこそ面白い

Atom で件数取得

山田さんの資料

Paul Prescod の Common REST Mistakes

第八回XML開発者の日

Windows Vista の RSS パーサは Well-formed XML のみサポート

XML 開発者の日、見どころ聞きどころ

Javascript+HTML のデザインパターン

microformats などの設計についていろいろ

良い URI の設計

Web らしく URI で連携する方向

そもそも ID を見つけるだけで十分なのだろうか

Hatena ID Auto-Discovery について

Atom 1.0

今後10年

Google Maps で世界のサーキット

はてなブックマークのタグ編集に Atom PP を用いる件について

Google Maps でみつけたもの

Microformats の夢

Microformats とは何か

REST -> AtomPP -> blog -> Permalink -> RSS/Atom -> Remixing (Ajax/Microformats/Folksonomy)

CDF を…覚えていますか?

REST 入門(その10) 終わりに

終わりに

REST 入門(その9) REST と SOAP

SOAP RPC と REST

WS-*/SOA

RESTful Web サービスの読みどころ: 4章リソース指向アーキテクチャ(ROA)

RESTful Web サービスの読みどころ: 3章　RESTfulサービスの特徴

第九回XML開発者の日終了