@IT会議室は、ITエンジニアに特化した質問・回答コミュニティ「QA@IT」に生まれ変わりました。ぜひご利用ください。
- PR -

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

投稿者投稿内容
NothingButXMLInfoSet
大ベテラン
会議室デビュー日: 2002/07/16
投稿数: 116
投稿日時: 2002-11-10 20:32
taiさん、詳細な解説ありがとうございます。とても参考になります。

引用:

問題は本来 URI で参照可能(よって GET など各種の URI ベースの機能が適用可能)とするのが適当な情報を POST の濫用で参照不能にしているからで、これは REST とも関連はしますが、基本的には先に biac さんが書かれたように

- http://www.w3.org/DesignIssues/Axioms
- http://www.w3.org/Provider/Style/Input
- http://www.w3.org/TR/html4/interact/forms.html#h-17.13

の話だと思います。


すみません、どれがRESTでどれが違うのかが私にはよくわかりません。AmazonがRESTという(あるいはWebという)アーキテクチャを念頭において設計されたシステムであれば、必然的に参照可能となるべき情報が、実際には参照可能でないということは、Amazonは別のアーキテクチャによって作られたシステムであるということになります。ところで、RESTというあーきてくちゃは、Webというものをよく表しているという定評がすでにあります。ということは、Web上に作られていながらRESTを念頭におかないと、何らかの弊害が出るはずです。その弊害が記事の冒頭で指摘した問題に表れていると考えました。

記事ではそれがPOSTになっていることを直接の原因として指摘してはいますが、この問題はFORMのMETHODをGETにすれば解決するものではありません。そもそも、「検索プログラム」に「パラメータ」として条件を与えるという思想自体が、すでにRESTアーキテクチャを念頭に置かない設計になっていると考えるからです。つまり、本記事で示した「オピニオン」は、POSTばっかり使うな!ということではありません。

では、なぜみんなPOSTを無闇に使うのでしょうか?この理由を私は2つ考えます。1つは、開発ツールによる安易なHTTPの隠蔽です。ASP.NETの例を示したとおりです。もう1つは、システムのアーキテクチャというものを無視する傾向です。システムを開発するときに、いきなりその問題領域で表れる「オブジェクト」の抽出から始めてしまうような開発スタイルでは、往々にしてオブジェクトの相互作用だけに目が向きがちで、その結果得られる「全体」がよく見えなくなってしまいます。

この2つ目の問題は、システム開発者の問題でもあるでしょうし、開発者を支援するツールベンダーの問題でもあるでしょう。上記の問題点1は、ツールベンダー自身がアーキテクチャを無視しているから生まれる問題だともいえますから。

私は実はRESTについてそれほど詳しいわけではありませんし、記事の中でRESTの解説をしようと思ったわけではありません。そうではなく、システムのアーキテクチャを考えないとどんなシステムが生まれるのかという視点です。あるいは逆に、なぜそのシステムは「変」になってしまったのか、という視点です。記事中で指摘しているASP.NETやAmazonの問題は、私の主張を裏付ける現象を示していて、それ自身が解決すべき問題であるといっているわけでは必ずしもありません。

引用:

面白いことに、Amazon.com が別途提供している API は RESTful で、通常のウェブの枠内で(GET/POST 誤用もなく)XML Web Service が提供されています。これと対照的なのが Google で、こちらは通常のウェブ検索は RESTfulですが、Google API はunRESTful になってしまいました。難しい…


これもよく言われている話ですが、どうもREST派の意見に私はナットクできないところがあります。この議論では結局、問題はGETかPOSTかだからです。SOAP 1.1のHTTPバインディングはPOSTの利用を強制しますが、それはSOAPはHTTPをトランスポートの一つとしてしか見ていないからです。SOAPにとって、HTTPなんて「どうでもいい、他で代替できるもの」です。

確かに、SOAPがPOSTを誤用しているために出てくる弊害はあるでしょう。たとえばPOSTのような動作を一切禁止するファイアウォールや、GETの結果をキャッシュできるプロキシがある場合、それら既存システムをSOAPベースシステムは活用できません。ですが、それはHTTPのGETを使えば解決する問題かといえばそうではありません。そもそもSOAPノードから返却される内容は、HTTPが想定しているようなデータではないからです。

SOAPはXMLに処理モデルを提供しようとしています。HTTPにはすでに処理モデルがあるので、その上に新しい処理モデルを加えれば摩擦があるのは当たり前です。ですが、SOAPにとってHTTPはOne Of Themです。HTTPにだけあわせたような仕様を作っても、SOAPの目標は達せられません。
tai
会議室デビュー日: 2002/11/09
投稿数: 3
お住まい・勤務地: 東京都
投稿日時: 2002-11-12 01:38
引用:

すみません、どれがRESTでどれが違うのかが私にはよくわかりません。(中略)ということは、Web上に作られていながらRESTを念頭におかないと、何らかの弊害が出るはずです。その弊害が記事の冒頭で指摘した問題に表れていると考えました。



これは私の書き方が悪かったです。すみません。
書かれていた Amazon の検索システムに REST 的でない所がある、という話自体はおっしゃる通りです。ただ、REST は単なる GET vs. POST ではなく、もう一歩踏み込んだ、インターネットスケールで展開するサービスについての根本的な問いである、ということを述べたかったがために、わざわざ補足する形となりました(が、意図としては同じだったみたいですね)。

引用:

この2つ目の問題は、システム開発者の問題でもあるでしょうし、開発者を支援するツールベンダーの問題でもあるでしょう。上記の問題点1は、ツールベンダー自身がアーキテクチャを無視しているから生まれる問題だともいえますから。



なんとなく NothingBut.NETFX さんは REST に詳しくないと書きつつ実は似たような問題意識を持たれているのかと思います。REST はまさにそのツールベンダに対してアーキテクチャレベルでの再考を迫っています。これは単に HTTP フレンドリにしろ、という話ではなく、両端にいるシステム開発者に対してどのような形態で見せるにしても、裏側の仕組みとして REST の要件を考慮することでウェブサービスの長期的成功をより裏打ちできるはずだ、という見直しの提案です。

引用:

これもよく言われている話ですが、どうもREST派の意見に私はナットクできないところがあります。この議論では結局、問題はGETかPOSTかだからです。SOAP 1.1のHTTPバインディングはPOSTの利用を強制しますが、それはSOAPはHTTPをトランスポートの一つとしてしか見ていないからです。SOAPにとって、HTTPなんて「どうでもいい、他で代替できるもの」です。



やはりこのあたりが最大の意見の相違点ですね。
問題は SOAP と HTTP の親和性ではないし、GET vs. POST のような話はどちらかというと瑣末な事項ではないかと思います。提起されているのは、SOAP(に代表される実装とその用法)に "Web Service" というモデルを支えられるだけのものがあるか、という問いではないかと思います。

たしかにおっしゃるように、SOAP は HTTP に限らず従来の仕組みに依存しない、自己完結的なものであろうとしています。しかし、その一方では SOAP を包容するウェブサービスという概念はウェブと不可分のものです。そして HTTP もウェブの一部でしかありません。

REST が SOAP に対して改良を加えようとしているのは、HTTP に準じるようにすることではなく、ウェブ(および未来の Semantic Web)の一環としてのウェブサービスを実現するためのモデルの見直しです。これは端的には URI 名前空間へのより緊密な結合という形の提案になっています。問答無用でアドレッシング不可能なリソースが増殖する単純なモデルでは(ウェブがそうであるような)リソース間の参照関係が積み上がる結果生まれるネットワーク効果が発揮できない、というわけです。

目指しているものは、従来のエンドポイントだけが URI 空間の端っこにあるモデルではなく、もっと深いレベルでの URI への統合と、その結果得られるより自由度の高い相互参照モデルです。HTTP への回帰は URI というアドレッシングモデルへの接近の帰結であって、他の(REST 要件として挙げられているような)メリットがあるにせよ、逆の流れではないと私は考えています。

実のところ、私も REST はともかく、REST/HTTP が絶対的に優れたモデルであるかどうかについては確信を持てていません。しかし、REST が提起する論点は検討に値するものであり、ウェブサービスの未来にとって非常に重要なものであるように感じています。おそらくツールキットレベルでの見た目はともかく、内部的にはこのアーキテクチャモデルにかなり影響された発展をみることになるのではないでしょうか。ご意見頂ければ幸いです。

スキルアップ/キャリアアップ(JOB@IT)