難しい...これもよく言われている話ですが、どうもREST派の意見に私はナットクできないところがあります。この議論では結局、問題はGETかPOSTかだからです。1.1のHTTPバインディングはPOSTの利用を強制しますが、それはSOAPはHTTPをトランスポートの一つとしてしか見ていないからです。SOAPにとって、HTTPなんて「どうでもいい、他で代替できるもの」です。確かに、SOAPがPOSTを誤用しているために出てくる弊害はあるでしょう。POSTのような動作を一切禁止するファイアウォールや、GETの結果をキャッシュできるプロキシがある場合、それら既存システムをSOAPベースシステムは活用できません。それはHTTPのGETを使えば解決する問題かといえばそうではありません。そもそもSOAPノードから返却される内容は、HTTPが想定しているようなデータではないからです。SOAPはXMLに処理モデルを提供しようとしています。HTTPにはすでに処理モデルがあるので、その上に新しい処理モデルを加えれば摩擦があるのは当たり前です。HTTPにだけあわせたような仕様を作っても、SOAPの目標は達せられません。01:38引用:すみません、どれがRESTでどれが違うのかが私にはよくわかりません。(中略)ということは、Web上に作られていながらRESTを念頭におかないと、何らかの弊害が出るはずです。その弊害が記事の冒頭で指摘した問題に表れていると考えました。これは私の書き方が悪かったです。的でない所がある、という話自体はおっしゃる通りです。なく、もう一歩踏み込んだ、インターネットスケールで展開するサービスについての根本的な問いである、ということを述べたかったがために、わざわざ補足する形となりました(が、意図としては同じだったみたいですね)。引用:この2つ目の問題は、システム開発者の問題でもあるでしょうし、開発者を支援するツールベンダーの問題でもあるでしょう。上記の問題点1は、ツールベンダー自身がアーキテクチャを無視しているから生まれる問題だともいえますから。詳しくないと書きつつ実は似たような問題意識を持たれているのかと思います。そのツールベンダに対してアーキテクチャレベルでの再考を迫っています。要件を考慮することでウェブサービスの長期的成功をより裏打ちできるはずだ、という見直しの提案です。引用:これもよく言われている話ですが、どうもREST派の意見に私はナットクできないところがあります。この議論では結局、問題はGETかPOSTかだからです。1.1のHTTPバインディングはPOSTの利用を強制しますが、それはSOAPはHTTPをトランスポートの一つとしてしか見ていないからです。SOAPにとって、HTTPなんて「どうでもいい、他で代替できるもの」です。このあたりが最大の意見の相違点ですね。ような話はどちらかというと瑣末な事項ではないかと思います。いうモデルを支えられるだけのものがあるか、という問いではないかと思います。限らず従来の仕組みに依存しない、自己完結的なものであろうとしています。包容するウェブサービスという概念はウェブと不可分のものです。ウェブの一部でしかありません。Web)の一環としてのウェブサービスを実現するためのモデルの見直しです。名前空間へのより緊密な結合という形の提案になっています。問答無用でアドレッシング不可能なリソースが増殖する単純なモデルでは(ウェブがそうであるような)リソース間の参照関係が積み上がる結果生まれるネットワーク効果が発揮できない、というわけです。統合と、その結果得られるより自由度の高い相互参照モデルです。要件として挙げられているような)メリットがあるにせよ、逆の流れではないと私は考えています。絶対的に優れたモデルであるかどうかについては確信を持てていません。提起する論点は検討に値するものであり、ウェブサービスの未来にとって非常に重要なものであるように感じています。ツールキットレベルでの見た目はともかく、内部的にはこのアーキテクチャモデルにかなり影響された発展をみることになるのではないでしょうか。ご意見頂ければ幸いです。Reserved.著作権はアイティメディア株式会社またはその記事の筆者に属します。当サイトに掲載されている記事や画像などの無断転載を禁止します。