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

» Permanent link | |

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

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

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

WEB+DB PRESS Vol.49

WEB+DB PRESS編集部

技術評論社 2009-02-24

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

» Permanent link | |

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シャツプレゼント企画

» Permanent link | |

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

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

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

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

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

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

» Permanent link | |

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 サービスクライアントの作成

» Permanent link | |

先週金曜日「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周年記念イベント

» Permanent link | |

来週 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サービス

» Permanent link | |

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 サービスの読みどころ: はじめに

» Permanent link | |

すでにオライリージャパンのサイトやメールニュースで新刊情報が流れていますが、 以前から何回か紹介してきた 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開発者の日に本書を持参していただければ、いくらでもサインします :-) (販売の予定はありません...)

ステートレスとは何か

» Permanent link | |

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

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

» Permanent link | |

ITpro Challenge 行ってきました。

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

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

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

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

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

檜山さんの記事

• XML ボキャブラリのデザインパターン
• XML ボキャブラリのアンチパターン

Tim Bray の記事

• Don't Invent XML Languages
• 日本語訳: もう XML 言語を開発するな

リンクは重要ですよ。

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

» Permanent link | |

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

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

» Permanent link | |

先月、ぐるなび 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

» Permanent link | |

以前言及したオ ライリーの 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

» Permanent link | |

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

S はシンプルの S

» Permanent link | |

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 関係のポスト に、対話形式を使うのを先を越されてしまった。 このうぬぼれはソクラテスの時代から使われてきたという事実を勇気を持つ材料にしよう。

第九回XML開発者の日

» Permanent link | |

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

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

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

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

REST 本

» Permanent link | |

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

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

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

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

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

本3冊

» Permanent link | |

しばらく時間が空いてしまいましたが、最近気になった本を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 編集部

日経SYSTEMS。

» Permanent link | |

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

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

これはそのとおり。

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

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

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

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

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

» Permanent link | |

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 の解説と、かなりツボを抑えている感じです。