REST勉強会 - kunit’s diary

OSC2008 Tokyo/Springの金曜日の夕方に「REST勉強会」とだけ告知して行いました。

内容をダンプしてみると・・・

スペシャルゲスト: 告知してませんでしたが、gihyo.jpでいろいろと興味深い記事およびムービーを出されている和田さん（id:t-wada）をゲストとしてお呼びしました。告知してたらまた違ったものになっていたかもしれませんが、おそろしく高度なものになっても対処できないので、伏せてやってみたということで・・・
参加人数: 正確に数えておけばよかったよ・・・38名の定員で席は3席くらいしか空いてなかったと思うので、30名以上はいたと思います。
アンケート: どんな人が集まったんだろうということで「どんな言語を使ってる？」ということを聞いてみました。結果は「Javaな人」が1/3で、残りのほとんどが「PHPな人」でした。Ruby/Python/Perl/JavaScriptを聞いてみましたが、それぞれ数名ずつで想像と違った偏り方をしましたね。Rubyな人たちばかりだったらどうしようとおもったりもしてました。まぁ、私がやるってことでPHPな人に偏るのは仕方がないところですかね。
アンケート2: 「RESTについてどんくらい調べてる？」ってことで、「RESTful本読んでる」ってのは10名いなかったですね。「WEB+DBのRESTの記事を読んでる人」ってのはこちらは10名は超えましたね。やっぱ「RESTful本」より雑誌の記事の方が気軽によめますからね。続いて「gihyo.jpのRESTの鼎談見た人」ってのはがくっと減ってこれまた10名はいなかったですね。「RESTって言葉くらいしかしらないんです・・・」って方も数名いらっしゃったので、まぁ想定してた通りの「ここから勉強を始めていこう」という会だったかなと。
RESTとは?: 私からRESTに関するおさらいをぱぱっとプレゼンさせてもらいました。まぁ、本当に最低限のものです。資料も後ではります。
最初のツッコミ: 和田さんから私のプレゼンに対して、早速ツッコミ。RESTの原則として「アドレス可能性の原則」と「統一インターフェースの原則」というものをあげさせてもらいましたが、より重要でより実現が難しい「ステートレス」と「connectedness」もきちんと押さえてよと。ここはgiyo.jpのREST鼎談でもきちんと説明があり、やっぱりきちんとそれを踏まえた資料にしておくべきでしたね・・・反省します。
最初の議題: 今回のセッションは討論会形式にしようということで、会場からなんかツッコミや疑問はありますか？ということではじめたところ、私のプレゼンの「200 OKとHTTPレスポンスを返して、その内容がエラー画面ってのは気持ち悪くない？」ってのに「404 Not FoundできちんとしたHTMLが返ってくる方が気持ち悪い」というツッコミがありました。これに関しては、会場からいろいろと意見がでて「WebサービスがXMLを返してくれるときに、200 OKが返ってきてるのにXMLをパースしたらエラーコード/エラーメッセージがわかるってのは面倒だ」とか、「HTMLを返すのとXMLを返すのでは違うんじゃないの？」とか、「そもそも現在のブラウザーがRESTの理想を実現可能ではないものだから回避策は必要だよね」とかという意見がでました。これに対して私から和田さんにどうでしょう？と無茶振りをさせていただいたところ、「現在のブラウザーがPUT/DELETEをうまく扱えないといったことも含めてRESTの理想を全て実現できないのは明らか。Webサービス/アプリケーションを作るときに、対象となるクライアントがシンクライアントなのかリッククライアントなのかといったことも踏まえて今日現在時点での落としどころを見つけていくってことが必要なのでは？」ということでなるほどなと。
2個目の議題: 私がRESTの説明を長々としてしまったために、この2個目までしかできませんでしたが、今回私がこのコマをやった最大の目的だった議題がでたので便乗。「WebサービスとWebアプリケーションではアプローチの仕方がかわるんでないかい？」という議題に対して、私から便乗して乗っけた議題が「確認画面ってどう扱うの？」でした。Webサービスだと、1つ1つのリクエストで取得/更新/削除/追加ということを直接実行してしまいますが、「確認画面」は実行してしまうというニュアンスではないので、これってどうよと。会場から出たのは「入力⇒確認⇒完了というようなフローを処理する場合、入力に遷移する際にPOSTで『ドラフト』というようなリソースを作成し、入力された内容をその『ドラフト』リソースにPUTで追加して、完了する際にその『ドラフト』リソースをPOSTすることによって、正式なリソースができるって感じ？」とか、「確認っていう振る舞いを素直に増やしたらいいんでないの？」とか、「それだと統一インタフェースにならないよ」とか。こちらも和田さんに無茶振りをしたところ、「ドラフトのようなWebサービスには必要ではないリソースをWebアプリケーションを作るうえでは準備しないといけない局面は出るだろうと。このあたりはWebアプリケーションの「REST層」と「プレゼンテーション層」とのギャップになるので、それはうまく吸収できるフレームワークを使ったり、自分で吸収できるように作ったりという実装者側の努力がしばらくは必要かもね」ということでこちらもなるほどなるほどと。

長々と書いたものを見てもらうとわかりますが、45分（実は使った会場が次の予定がないことをいいことに10分くらい延長した）という短い時間にものすごくいい議論ができたなぁと。これはまたやらないといかんすね。

あと、Maple×Usagiのコラボとして、身内でのもっとディープなREST勉強会ってのをOSCが終わったあとの夕方に場所を移してやりました。私は仕事の都合でどうしてもいけずに和田さんとコラボのメンバーだけで行われたんですが、こちらはみっちり3時間、おそろしく濃い内容を話したようです。くやしー。

そのディープな勉強会の結果、「やっぱ基礎は重要」ということで、「RESTful本読書会」をしないといかんなぁと。この本はものすごくいい本なんですが、RESTってなにさ？って人が一人で読み進めるのはつらいなと感じる本なんですよね。なので、ちょっと月一ペースで読書会をしてみようかと。

で、その読書会でやってみたいのが「Ruby札幌メソッド」です。なにかというと「会場の映像をUStreamで配信して、プロジェクター2台準備して、1台は発表資料、1台はIRC画面」というものです。読書会を開催してどのくらい人が参加したいと思うかもわかりませんが、東京で開催したら参加できないメンバーもいるし、そこから突っ込みや質問ができる状態にするのがこれからの勉強会/読書会のあるべき姿かなぁと。

ただし、恐ろしく機材やネット環境の準備が必要となるので、まずは会場の確保を考えないといかんすね・・・土曜日の午後で、プロジェクター2台準備できて、ストリーム配信できるネットが使えて・・・ってあるんかいな。

少なくともうちの会社は会議室が狭すぎなので、「うちの会社を使ってよ」とか「ここの会場が安くていいよ」とかの情報をお待ちしてます。

PHP勉強会とかぶらない3月後半あたりの土曜日ということで第1回をしたいと思ってますので、ご協力よろしくお願いします。

追記: プレゼン資料をはるのを忘れてたよ。こちらからどうぞ ⇒ http://kunit.jp/docs/OSC2008-Tokyo-Spring-REST.pdf