すらいむがあらわれた

こまんど　＞　　たたかう　　にげる

第八回XML開発者の日

行ってきました。

  • REST入門 山本陽平(株式会社リコー)

もんたメソッドだ…。ま、それはおいといて(w
yohei-y:weblog REST 入門
http://yohei-y.blogspot.com/2005/04/rest_23.html
の内容を、書いた本人自ら解説。
正しいRESTとは！といった講義をたっぷり聴いた。

先ほどまでの理想論をふまえ、ここからは現場の話が始まります。
id:naoya氏からはてなブックマークAPIの実装についての解説。
はてなはもともとURLをシンプルなものにしようという開発方針だったそうで、自然とRESTを採用する方向になっていったそうです。
ただ、純粋にRESTをやるのはややこしい場合もあるとのこと。
はてなブックマークAPIと対照的なAPIとしてdel.icio.usのAPIが紹介されていました。

  • RESTful Wiki の実装 gorouこと舘野祐一(株式会社ディノ)

gorou(id:secondlife)さんはRSSTIMES（この日記の右上にでてるバーコード）などのおもしろツールも公開してくれてます。 使わせていただいてます(^^)
gorouさんのはてなダイアリーはオシャレで、みてて楽しい。実はこのはてダで「Ruby on Rails」の存在をしりました。なんか楽しそうにみえる。


発表で出てきた「RESTWiki」はこれ。
RESTWiki
http://rails2u.com:8008/
川o・-・）＜2nd life - RESTWiki
http://d.hatena.ne.jp/secondlife/20050914/1126631161
RoRがRESTを実装してなかったので自前で実装し、インターフェイスはprototype.jsのAjax機能とgorouさん自作のGizaというJavaScriptライブラリで作ったそうです。
聴いたことのメモ。
・Ajaxは大変。サーバー側の実装時間の５倍くらいクライアント側実装に時間がかかった。
・RESTもGETとPOSTしか対応してないブラウザがあるなど問題が。
・Ajaxだと外部ドメインのXMLを呼べない（回避方法があるにはあるが）

TackBackの実装に関する話を聴けるかと期待しましたが、6Aの紹介のみでちょっと残念。

アルファギーク揃いの今回の発表者のなかではあまりネットで名前が知られていない方だったのですが、発表内容の有益さはダントツ一番でした。発表資料どこかで公開していただけるとうれしいですm(_ _)m
以下聴いた内容のメモです。
・RSS,Atomはフォーマットが分散しすぎ。データ形式の統一が必要。
・RESTはサーバーサイドの実装が大変。クライアントは楽だけど。あるREST APIからまたさらに別のRESTを呼ぶといった処理の実装はややこしい。
・RESTは認証の問題がある。

高橋メソッドを堪能しました。それはおいといて(_ _;
認証の問題の解決策として、本当に認証が必要な部分と、それ以外の部分を別のREST APIに分ける、などの方法を提案されてました。
あと、REST+Ajaxの使いかたによっては、URLが特定のリソースを表しているはずがJavaScriptで動的にコンテンツを生成しているせいでそうならなくなってしまうという指摘も。

Mark Baker氏の資料が簡単すぎるから…という理由で10分でささっと終わられてしまいました。時間調整の都合があったみたい。

上記の参加者に加えてたしかインフォテリアの方もいらした気がする。
パネルディスカッションは盛り上がっていたのですが、ちょっと話の内容は忘れてしまいました…。アンチXML Schema、アンチSOAP、アンチJavaだったような。


最後に全体的な感想として、RESTの利点、欠点がおおむね洗い出されたなあと思いました。
利点
クライアント側が使いやすい。（わかりやすいURL、簡単に使えるAPI）
仕組みがシンプル、HTTPの知識だけで理解できる
RESTでURLをきれいにすることがSEOにもなる（Googleなどの検索ロボットはパラメータつきURLを避けがち？）
欠点
セッションをもてないため、認証の処理に問題がある。このためクリティカルなシステムの構築に向かない
サーバー側実装が大変。
実はPOSTとGETにしか対応してないブラウザがあるなど、現実にはきれいなRESTができない場合も。


こういった利点を十分に生かせるのはやはりWebベースサービス（主にBlog）で、エンタープライズ（イントラ用業務アプリ）ではあまりRESTのメリットがなく、そもそも認証の問題があってあまり実用的ではなさそうです。
BlogをはじめとするWebベースサービスではいかにユーザーに見に来てもらうか、自分のところのサービスを広めてもらうかが大事なので、ユーザーにわかりやすいURLをつけるとかホビープログラマ向けにURLをGETすればだらっと生のXMLデータがとれるようにするとかは手間がかかってもそれだけの価値があるんですよね。でもエンタープライズのアプリだとそのあたりに手間をかけても元手が回収できません。
じゃあエンタープライズはSOAPだね！という話になるかと言うと…そもそも認証がどうとか言っている前にSOAPはRESTでできる簡単なデータ交換ですら普及できなかったわけですから…。
今回のXML開発者の日はLL何とかなのか？と思うくらいアンチJavaなスクリプト系言語プログラマの集まりになってしまってたようですが、こういうスクリプト系言語にとってのWebサービスはもうRESTで決まりになってしまったのかなあ？
大手のWebベースサービスではPerlやPHPで開発しているところが多いと思いますので、こうした言語でRESTがデファクトになってしまったらもう彼らにSOAPは使ってもらえないでしょう。
となると、SOAP+WSDLでプラットフォーム非依存なんてやっぱできなかったってことかなあ。



まあエンタープライズ分野としてはJavaと .NETがつなげればいいやって話なのかもしれないけど、それもまだまだ先っぽいですね。