「Ruby on Rails 2.0」が公開 〜SOAPの代わりにRESTの利用を推進

「Ruby on Rails 2.0」が公開　〜SOAPの代わりにRESTの利用を推進

メインタイトルだけなら、他の専門の方におまかせするつもりでしたが、サブタイトルで、XML Consortiumや、IT Proのサイトで、SOAP vs RESTを議論してきたものとして、感慨を覚えるものがあり、コメントしてみることにしました。

　Hansson氏は、Ruby on Rails 2.0の開発にあたり、「RESTの考え方と、RESTフルなアプリケーションの構築法を推進することに重点を置いた」と述べている。

こちらの本は2007年10月出版ですが、

RailsによるアジャイルWebアプリケーション開発 第2版

原書は１年半くらい前に出ているので、「２５章 RailsのWebサービスのところ」でも、SOAP/WSDL、XML-RPCの典型的な使い方をサポートするAWS (Action Web Service) の記述が中心となっています。ただし、章の初めの段落がいきなり括弧で始まっていてゴシック体の小さい字で次のように書かれています：

（この章は静かな論争の的になっています。RailsがRESTをサポートするようになり、コアチームは、XML-RPCベースやSOAPベースのWebサービスにいままでほど興味を持たなくなりました。Action Web Serviceは、Railsの中心から外され、Rails2.0ではプラグインになります。外部インタフェースに束縛されない新しいアプリケーションのために、軽量のRESTを使うほうを考慮したくなるかもしれません。・・・）

そして、昨日(2007/12/10)のこの翻訳記事によれば、「以前のRuby on Railsは、SOAP Webサービスを使用するライブラリとともに提供されていた。だが、われわれはこのライブラリに見切りをつけ、代わりにREST Webサービスの利用に特化した要素を多数盛り込んだ」とあります。

その理由はやはり、「控えめに言っても、こうした（WS-*の）標準を使うと、何事もシンプルに進まない」として見切りをつけたことにありました。
確かに、WS-*で仕事ができる人はスーパーエンジニアなのかもしれません。しかし、Web2.0系の、要求開発自体と表裏一体でアジャイルに進めるべきプロジェクトにはやはり無理がある、という感想をもたざるを得ないものもあります。

「われわれは、SOAPは複雑化しすぎていると感じている。この技術は大企業の人々が主導権を握っているが、そうなると大抵いいことはない。それに対してRESTは、HTTPやプレーンなXMLなど、Webの基本的な標準に基づいている」

→この言い方からは、WS-*自体が、大企業グループによる技術プラットフォームの囲い込み、独占の産物だったのではないか、という主張が垣間見えます。しかし、その主張には個人的には反対です。２００１年のSOAP/WSDL/UDDI誕生の当時、これらは、各企業群のプロプラな分散オブジェクト技術を捨てて、XMLベースで統一的標準を作ろう、という意図で作られたからです。SOAPは今はSOAPですが、Simple Object Access Protocolということで、当時の常識からは、非常にシンプルなものでした。しかし、Roy Fieldingの博士論文でRESTアーキテクチャ・スタイルが、Webの基礎技術の優位性を追認して以来、また、実際に多用されるようになり、究極的にシンプルなWebServiceが追求され、【新しい】運用上もそれで十分じゃないか、という経験、ノウハウがたまってきたわけです。

SOAP/WS-*関連で数百の言語を知っておき、適宜使い分けられるように学ばねばならなくなったのは、エンタープライズの基幹システム、既存システムの置き換えをWebサービスベースで行おうとしたから、といっていいでしょう。Web内部に(下層ではVPNに比べられるような)専用のXML層のデータ授受チャネルを設けて、セキュリティやトランザクション保証なんかも行う、というシステムで、且つ、業務の流れ、ひいてはデータの流れも従来のビジネスでのやり方を踏襲するのであれば、これだけ複雑化するしかなかった、という見方も正しいように思います。

しかし、さすが、Getting Real の37signalsの人。RESTに集中したのは恐らく、今後とも、正しい選択だったといえるでしょう。大企業のSOAの中でも、RoRベースのWebアプリは独立のサーバ上でシンプルに動かし、RESTで疎結合に組み込んでいけば良いような気がします。これで不都合な業務プロセスがあれば、業務プロセス自体をシンプル化してしまう、という覚悟の上で。論理的には本末転倒ですが、これが現実的な解という気がします。多くの業務プロセスは過去のテクノロジーを前提とした慣習から成立しており、様々な合理性を深く追求しての産物ではないようですので。

さらに、Ruby on Rails 2.0では、「ActiveResource」という新たなコンポーネントが提供される。これは、Webサービスをカプセル化し、データベースのように簡単に利用できるようにするものだ。

WebサービスをActiveRecordでデータベースを扱うように、メタプログラミング的に簡便に扱えるというのは良いことでしょう。どうせなら、返り値のデータ型の違いまで自動吸収！というノリまでいっちゃえー！と、応援したい気持ちになります。そうなった暁には、さしものPHP人口も雪崩をうってRuby on Railsに移動してきてくれそうな気がするから。

注：http://api.rubyonrails.org/　の　vendor/rails/activeresource/READMEをざっと見た限りでは、返り値のデータ型の違いまで自動吸収してくれるようには読めませんでした。→ある程度できても全然おかしくないと思うんだけどなぁ。詳しい方、教えてくださーい！　

以下、http://api.rubyonrails.org/　より：

Active Resource (ARes) connects business objects and Representational State Transfer (REST) web services. It implements object-relational mapping for REST webservices to provide transparent proxying capabilities between a client (ActiveResource) and a RESTful service (which is provided by Simply RESTful routing in ActionController::Resources).

ActiveResource::Base documentation より：

Lifecycle methods
Active Resource exposes methods for creating, finding, updating, and deleting resources from REST web services.

Authentication
Many REST APIs will require authentication, usually in the form of basic HTTP authentication. Authentication can be specified by putting the credentials in the site variable of the Active Resource class you need to authenticate.

class Person < ActiveResource::Base
self.site = "http://ryan:password@api.people.com:3000/"
end

アクセスキーが必要なWebAPIに対する認証がこんなに簡単に書けるのは嬉しい。