最近の記事において、 William Vambenepe氏は、IT/クラウド管理の実用的な価値を調べるため、公開されている4つのクラウドAPI (AWS EC2、GoGrid、Rackspace、Sun Cloud)を比較している。
興味深いことに、WS-* 群の創出に関係した人間として、 William氏にとってRESTの原則は自然なものに思える。
WS-*とは反対のものですが、最先端の技術がCGI Perlスクリプトだったときに、ウェブアプリケーションを書き始めた人、電信プロトコルを愛する人 […]、XMLをそのまま扱うのが楽しい人 […]、セマンティックウェブを高く評価する人、そして、プロトコルよりもモデルを重視する人として、RESTの原則は、私にとってとても自然なものです。
ITリソース管理の経験をふまえて、この分野におけるRESTfulな原則と、様々なIT/クラウド管理ベンダがAPI設計にこれらの原則をどのように利用するのかについてWilliam氏は調査している。
しばらくの間、私はRESTに関して何か重要なことを見逃しているのではないかと思っていました。それは、IT管理にも当てはまります。それとも、これは“ただ一つのプロトコルを選び、モデルに注目するだけの問題”でしょうか。(ただ他に選択できる方法の様々な欠点を避けることと同じように。これは、正当な理由ですが、RESTに本来備わっている利益ではありません。)
William氏は、Amazon EC2 のちょっとした歴史について書き始めた…
Amazon EC2 APIが2、3年前に出てきて、SOAPと同等のものや単純なHTTPの代案であったとき、ただプロトコルを選んで変えないことが問題だという考え方を動かすものは何もありませんでした。単純なHTTPか、SOAPの選択肢を与えましたが、 それは、ただ、どのようにメッセージをシリアライズするかという問題でした。(入力がURLパラメタか、SOAPメッセージかどうか。いずれにしても出力はSOAPラッパーでした。)
[…]
2009年まで話を進めると、今や多くの人たちがクラウドコンピューティングのためにRESTfulなAPIを作成して公開しています。これらは、実際の実装によって裏付けられたAPIであり、明確にRESTfulであることを要求しています。(Amazonとは異なります) さらに、APIを作った人たちは、データセンターの自動化やREST設計に大きな信頼を得ています。最初は、GoGrid、次に、Sun Cloud API、そして、最近は、Rackspace。だから、今、私たちは、リソース管理にとってRESTが何を意味するかを理解するように分析する具体的な仕様書を持っています。
… 続けて、GoGrid API、Rackspace の“クラウドサーバ” API、Sun Cloud APIを検討している。それから、William氏は、様々なクラウドベンダは提供するものがどれも似通っているとし、機能の詳細な比較はせずに結論を出した。 He concludes, without going into a detailed comparison of the features that the various cloud vendors are very similar in their offerings
全体的に、これらは多くの面から見てかなり似ています。これらを使って、同じようなことができます。(画像に基づいてサーバインスタンスを作成し、それらを破壊し、IPを割り当てる…) いくつかの機能は異なります。GoGridは、ロードバランシング機能をより良くサポートします。Rackspaceでは、バックアップスケジュールの制御ができます。Sunは、クラスタを提供します。(EC2 API固有のグループとして管理する機能のようなものを実現する方法です。)
William氏は、SunとRackspaceのAPIがもっともRESTfulであると結論付けている。その結果として、これら2つを使って開発するのは最高におもしろいものになるだろう。この記事は、William氏のブログで見つけられる。これらのクラウドベンダのAPIを使って開発した経験はあるだろうか? 特に、William氏の分析から明らかにもれているベンダであるMicrosoftのWindows Azureを使っているだろうか?