Webの「正しい」アーキテクチャ

インフォテリア株式会社
吉松 史彰
2002/11/07


 ブラウザとWebサーバの組み合わせで作られる、いわゆるWebアプリケーションの開発が盛んだ。それまでのクライアント/サーバ・システムにおいて悩みの種だった新バージョンの配布や保守の問題が解決され、システム管理者が楽になったのが理由であるといわれている。しかし、クライアント/サーバ・システムを開発していた開発者にとっては、Webは非常にシステムを作りにくい環境だった。貧弱な機能しか持たないブラウザと、単純なデータしか送信できないプロトコルを利用して、これまでどおりのLook and Feelのアプリケーションを作れというのだ。どだい無理な話である。

 だが、開発者には味方がいた。開発ツール・ベンダである。開発ツール・ベンダは、Webアプリケーション開発者が悩んでいるのをビジネス・チャンスと考えた。その結果、さまざまなWebアプリケーションの開発環境が作られた。それらすべての開発環境に共通しているのは、Webの仕組みを開発者から隠ぺいしようとしているということである。ASP.NETを見てほしい。Java Community Processは「Java Server Faces」という技術を開発中だ(http://java.sun.com/j2ee/javaserverfaces/)。これらはいずれも、Visual BasicやDelphiのようなWindowsアプリケーションの開発環境と同じような開発手法を、Webアプリケーションにも提供しようとしている。よかった、IT業界のみんながようやくハッピーになった。

 いや、実はハッピーでない人たちがいた。アプリケーションのユーザーだ。例えばwww.amazon.co.jpにアクセスしてみよう。左上の方に「サーチ」という項目があり、Amazonのデータベースを検索できる。「吉松史彰」と入力して検索すると、せんえつながら3件ほど結果が表示される。さあ、せっかく天下の@ITでここまで書かせていただいたのだから、読者の皆さんにもぜひそのページにアクセスしていただいて、筆者がかかわった3冊の書籍を見て(買って)ほしい。こういうとき、Webの仕組みに慣れている読者ならどうするだろうか? そう、恐らくブラウザの「アドレス」欄に入っているURLをコピーして、この文章にペーストするに違いない。ここでもそうしてみよう。下記のURLをクリックしてみてほしい。

http://www.amazon.co.jp/exec/obidos/search-handle-form/249-4308483-4858721

 どうだろうか……。「ブラウザのバグ?」いやいや、これはブラウザのバグなんかではない。秘密は次のHTMLにある。HTTPのPOSTを使って検索条件を送信しているので、その情報を送り直さない限り、Amazonのデータベースには検索条件が渡らない仕組みになっているわけだ。

<form method="post" action="/exec/obidos/search-handle-form/249-4308483-4858721">

 こんなことは、Webアプリケーションの開発者にとっては常識だろう。だが、ユーザーにとってはどうだろうか? ブラウザのメニューにある機能のうちでも、最も頻繁に使われる機能は何だろうか? 恐らく「お気に入り」「ブックマーク」機能だろう。URLなんかいちいち覚えてはいられない。@ITの読者だって、有益なページを見つけたら、迷わず「お気に入り」として登録するのではないだろうか。Amazonの検索エンジンはそれを許してくれない。

 Apache Software Foundationの共同創立者にしてBoard of Directorsの1人であるRoy Fieldingが書いた論文が、このところ注目を集めている。「REpresentational State Transfer」、略してRESTと呼ばれているアーキテクチャを提案したその論文は、特にWebの世界をよく表しているとしてW3Cなどで取り上げられている。RESTの内容をWebの世界に当てはめると、要するにこういうことになる。

  • Webサイトが保持していて、外部に公開される内容には、すべて(論理的な)URI(URL)が付いていなければならない。
  • Webサイトへのアクセスは、HTTPのPUT(Create)、GET(Read)、POST(Update)、DELETE(Delete)で行い、それぞれ処理内容に合わせた結果が返されなければならない。
  • Webサイトへアクセスした結果返されたものがリソースの表現(Representation)であり、ページからページへの遷移が状態の遷移(State Transfer)と見なされる。

 つまり、Amazonの仕組みはRESTのアーキテクチャに従っていないということだ。この場合、「『吉松史彰』という情報が含まれているデータ」というリソースにアクセスするURLがあれば、この文章にそれをコピーして、後で読者の皆さんにアクセスしてもらえただろう。だが、Amazonのサイトでは「『吉松史彰』という情報が含まれているデータ」が外部に公開されているにもかかわらず、そのデータを一意に識別できるURLが存在しないのである。その結果、Webの最も重要な機能であるリンクが使えなくなっているのだ。リンクが使えないとブックマークもできないし、ページを次々とたどることもできない。

 ちょっと難しかっただろうか。それでは次の例を考えてほしい。Webサービスでよくある「株価照会」の例だ。

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
  <ns1:getQuote
    xmlns:ns1="urn:xmethods-delayed-quotes"
    SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
      <symbol 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バインディングによるアクセスをサポートしている。SOAP HTTPバインディングは、仕様上はHTTP POSTを使うように指示している。つまり、上記のSOAPメッセージはPOSTで送らなければならない。しかし、POSTで送ると先ほどのAmazonの検索と同じ結果になる。友人にMSFTの株価を照会するためのリンクを教えてあげようにも、そのリンクが存在しないのだ。いくら上記のURLへアクセスしても、正しいPOSTデータを送らなければ、株価は取得できない。SOAPのHTTPバインディングは、Webで最も重要な「リンク」という概念を無視して作られている。それはWebへの裏切りにほかならない。Webを無視しておいて「Webサービス」などとよくいったものだ。このような批判が、ここ最近W3Cで繰り返されている*1。XML Protocol Working Groupがこの批判を受け入れた結果、SOAP 1.2の現在のドラフトにはHTTPバインディングでGETを利用する手順が追加されている。

*1 例えばhttp://www.w3.org/Search/Mail/Public/search?type-index=www-tag&index-type=t&keywords=RESTを見てほしい。

 Webアプリケーション開発の話とつながっただろうか。ASP.NETのWebフォームも、HTTP 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は会社の後輩にメールで送って意味があるだろうか。End of Article


吉松 史彰(よしまつ ふみあき)
 インフォテリアにおいて、.NET FrameworkやXMLを活用したシステムの開発とコンサルティングを行っている。また、個人でも執筆や講演活動を通して.NET Frameworkの啓蒙活動をマイクロソフトに黙って勝手に行っている。

 「Insider.NET - Opinion」

@IT Special

- PR -

TechTargetジャパン

Insider.NET フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

イベントカレンダー

PickUpイベント

- PR -

アクセスランキング

もっと見る

ホワイトペーパーTechTargetジャパン

注目のテーマ

Insider.NET 記事ランキング

本日 月間
ソリューションFLASH