史彰2002/11/07ブラウザとWebサーバの組み合わせで作られる、いわゆるWebアプリケーションの開発が盛んだ。それまでのクライアント/サーバ・システムにおいて悩みの種だった新バージョンの配布や保守の問題が解決され、システム管理者が楽になったのが理由であるといわれている。クライアント/サーバ・システムを開発していた開発者にとっては、Webは非常にシステムを作りにくい環境だった。Feelのアプリケーションを作れというのだ。開発者には味方がいた。開発ツール・ベンダである。開発ツール・ベンダは、Webアプリケーション開発者が悩んでいるのをビジネス・チャンスと考えた。その結果、さまざまなWebアプリケーションの開発環境が作られた。それらすべての開発環境に共通しているのは、Webの仕組みを開発者から隠ぺいしようとしているということである。ASP.NETを見てほしい。Faces」という技術を開発中だ(http://java.sun.com/j2ee/javaserverfaces/)。BasicやDelphiのようなWindowsアプリケーションの開発環境と同じような開発手法を、Webアプリケーションにも提供しようとしている。よかった、IT業界のみんながようやくハッピーになった。いや、実はハッピーでない人たちがいた。アプリケーションのユーザーだ。www.amazon.co.jpにアクセスしてみよう。左上の方に「サーチ」という項目があり、Amazonのデータベースを検索できる。「吉松史彰」と入力して検索すると、せんえつながら3件ほど結果が表示される。ブラウザの「アドレス」欄に入っているURLをコピーして、この文章にペーストするに違いない。ここでもそうしてみよう。下記のURLをクリックしてみてほしい。http://www.amazon.co.jp/exec/obidos/search-handle-form/249-4308483-4858721どうだろうか......。「ブラウザのバグ?」いやいや、これはブラウザのバグなんかではない。秘密は次のHTMLにある。HTTPのPOSTを使って検索条件を送信しているので、その情報を送り直さない限り、Amazonのデータベースには検索条件が渡らない仕組みになっているわけだ。action="/exec/obidos/search-handle-form/249-4308483-4858721">こんなことは、Webアプリケーションの開発者にとっては常識だろう。「お気に入り」「ブックマーク」機能だろう。URLなんかいちいち覚えてはいられない。@ITの読者だって、有益なページを見つけたら、迷わず「お気に入り」として登録するのではないだろうか。Amazonの検索エンジンはそれを許してくれない。Fieldingが書いた論文が、このところ注目を集めている。Transfer」、略してRESTと呼ばれているアーキテクチャを提案したその論文は、特にWebの世界をよく表しているとしてW3Cなどで取り上げられている。RESTの内容をWebの世界に当てはめると、要するにこういうことになる。Webサイトが保持していて、外部に公開される内容には、すべて(論理的な)URI(URL)が付いていなければならない。Webサイトへのアクセスは、HTTPのPUT(Create)、GET(Read)、POST(Update)、DELETE(Delete)で行い、それぞれ処理内容に合わせた結果が返されなければならない。Transfer)と見なされる。Amazonの仕組みはRESTのアーキテクチャに従っていないということだ。いう情報が含まれているデータ」というリソースにアクセスするURLがあれば、この文章にそれをコピーして、後で読者の皆さんにアクセスしてもらえただろう。Amazonのサイトでは「『吉松史彰』という情報が含まれているデータ」が外部に公開されているにもかかわらず、そのデータを一意に識別できるURLが存在しないのである。その結果、Webの最も重要な機能であるリンクが使えなくなっているのだ。リンクが使えないとブックマークもできないし、ページを次々とたどることもできない。それでは次の例を考えてほしい。Webサービスでよくある「株価照会」の例だ。xsi:type="xsd:string">MSFT</symbol></ns1:getQuote></SOAP-ENV:Body></SOAP-ENV:Envelope>このWebサービスのWSDLを読むと、このサービスは「http://66.28.98.121:9090/soap」というURLでSOAPのHTTPバインディングによるアクセスをサポートしている。POSTを使うように指示している。上記のSOAPメッセージはPOSTで送らなければならない。POSTで送ると先ほどのAmazonの検索と同じ結果になる。友人にMSFTの株価を照会するためのリンクを教えてあげようにも、そのリンクが存在しないのだ。上記のURLへアクセスしても、正しいPOSTデータを送らなければ、株価は取得できない。SOAPのHTTPバインディングは、Webで最も重要な「リンク」という概念を無視して作られている。それはWebへの裏切りにほかならない。Webを無視しておいて「Webサービス」などとよくいったものだ。このような批判が、ここ最近W3Cで繰り返されている*1。1.2の現在のドラフトにはHTTPバインディングでGETを利用する手順が追加されている。http://www.w3.org/Search/Mail/Public/search?type-index=www-tag&index-type=t&keywords=RESTを見てほしい。Webアプリケーション開発の話とつながっただろうか。POSTを前提に作られている。筆者はほかのWebアプリケーション開発環境を使ったことがほとんどないのだが、恐らくどれも似たようなものだろう。世の中に同じ問題を抱えたWebサイトがあふれかえっているからだ。Webサイトにアクセスし、とても有益な情報を見つけたユーザーが、それを友人に伝えるためにリンクを使うのは当たり前だ。それができないサイトは、「口コミ」というマーケティング・ツールを自ら放棄したことになるのだ。RESTアーキテクチャは、開発者と管理者の利便性ばかり考えて、エンドユーザーの利便性を考えてこなかったIT業界への絶縁状なのだ。HTTPが生み出されたときに、GETとPOSTとPUTを分けたのにはきちんと理由がある。それを無視して無理を通せば、誰かの道理が引っ込まなければならない。いまのところ、道理を引っ込ませているのは、本来最も優遇されるべきエンドユーザーなのだ。Webアプリケーションは、ほかの形態のアプリケーションにはない利点を持っている。それを生かすも殺すも開発者次第だ。開発したシステムが持つ1つ1つのリソースには、それにアクセスするURLがあるだろうか。エンドユーザーが、上司への報告書の中でそのシステムが提供する重要な情報(例えば今月の売り上げ一覧)を参照したい場合、彼はどうするだろうか。「ホームページを開いて、〜〜というリンクをクリックして、3つ目のテキスト・ボックスに『10月』と入力して一覧ボタンを押してください。」などとメールに書くのだろうか。そのシステムはなぜWebベースになったのか、そのアーキテクチャの選択理由をもう一度考えてほしい。システムのアーキテクチャを無視すれば、どこかでその代償は払わなければならないのだ。その代償はWebアプリケーションのユーザーが払っているように見えて、実は次の案件がなくなるという形で開発者が払っていることにそろそろ気付かなくてはならないだろう。それなら@ITのトップページを見てほしい。上部に「IT用語・記事検索」という欄がある。横のテキスト・ボックスに、例えば「SOAP」と入力して検索ボタンを押してみよう。ブラウザのアドレス欄にどんなURLが表示されているだろうか。そのURLは「SOAPとは何か?」を知りたがっている会社の後輩にメールで送って意味があるだろうか。今度は、もう一度トップページに戻り、「IT用語・記事検索」という言葉(リンクになっている)をクリックして検索のページに進んでみよう。検索欄にもう一度「SOAP」と入力して検索ボタンを押してみる。検索結果はさっきと比べてどうだろうか。今度はブラウザのアドレス欄にどんなURLが表示されているだろうか。そのURLは会社の後輩にメールで送って意味があるだろうか。FrameworkやXMLを活用したシステムの開発とコンサルティングを行っている。Frameworkの啓蒙活動をマイクロソフトに黙って勝手に行っている。7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。TranslatorはPowerPoint用のアドイン。