FlashでRESTfulなサービスを構築する

作者 Mark Little , 翻訳者 大田 緑 - (株)チェンジビジョン 投稿日 2010年8月18日

セクション

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ

トピック

WS Standards ,

Webサービス ,

Flash ,

RIA ,

SOA ,

REST ,

Adobe ,

Architecture ,

エンタープライズアーキテクチャ

共有 |

原文(投稿日：■)へのリンク

Flashは数多くの評判の良いウェブサイトの中心となっている一方で、評判を落とす元にもなっている。広く使われているにも関わらず、現在、RESTfulな方法では使えないか、使うのが難しいようだ。どうやらFlashブラウザはGETかPOST操作のみに対応する。PUTとDELETEをシミュレートするためにPOSTをオーバーロードできず、クッキーは動作しない。(著者注:REST アンチパターンを調べよう!) 幸いにも、OASIS SOA Reference Model TC の共同議長であり、AdobeエバンジェリストのDuane Nickull氏が記事に関して以下のように述べている。

Flashは正しく発展してきており、SOAのOASIS Reference Modelによって定義されるように、SOAの中心原則と合致します。この抽象モデルは、Roy Fielding氏のRESTに関する博士論文と同じ抽象レベルで、SOAの中心原則を記述します。Flashは、RSETの中心原則とも合致します。

Duane氏やその他の人たちが指摘した通り、RESTはHTTPに関連していない。他の技術を使って、RESTfulなサービスを設計することは完全に可能だ。Duane氏は、GETとPOSTだけがサポートされるべきであり、これは基本的なSOAの要求に関係すると信じる理由について述べている。

アプリケーションを構築するSOAのような方法は、可能なところではデータ管理のセマンティクスをトランスポート部分から外しておくことです。これに関して、決まったルールがある訳ではないが、私が話した多くのアーキテクトたちは、これが最高の構築方法だと確信しているようです。各サービスは、サービスの呼び出しを処理するために、関連するデータモデルとアクションモデルがあります。データモデルはデータ、処理/アクションモデルはサービスの呼び出しの「動詞」を表現できる場所です。

理想を言えば、アーキテクチャのレイヤは、可能な限りお互いに独立しているべきだ。これは、W3C Web Services Architecture ワーキンググループがSOAPの中でGETとPOSTだけをサポートすることを選んだ理由の1つだ。また、Flashの中で動詞のサポートが制限される理由でもある。この主張をサポートするために、Duane氏はRoy Fielding氏の論文 (6.3項)に言及する。この論文では、最初に以下のように述べている。

HTTPの問題のある主な分野でRESTによって認識されたのは、新しいプロトコルのバージョンを開発するために計画すること、HTTPセマンティクスと基底トランスポートレイヤ(TCP)からメッセージのパースを分離すること、信頼できる応答と信頼できない応答を区別すること、キャッシングを非常に細かく制御すること、そして、自己記述できないプロトコルの様々な側面などです。RESTはまた、HTTPに基づいてウェブアプリケーションのパフォーマンスをモデル化し、持続的接続やコンテントネゴシエーションのような拡張が影響することを予想するのにも使われています。結局、RESTは、HTTPを誤用するアプリケーションが等しく標準に影響を与えられることよりも、標準化されたHTTPの拡張範囲を構造的なモデルに合うものに制限するために使われています。

Duane氏は続けて、 アーキテクトがRESTやSOAを使っているかどうかには関わらず、GETとPOSTにとどまりたい理由について議論した。例えば、DELETEについて考えてみよう。DELETEは、特別なセマンティクスを明らかにするので、特定のサーバの信頼できないすべてのコンシューマが利用できる訳ではありません。

サービスのコンシューマにDELETEを明らかにしたい場合、私の好きな方法は、DELETEを明らかにする第二のサービスを構築しつつ、ペイロード(多くの場合、SOAP本体)のバックエンド処理のセマンティクスを維持することです。

PUT と POSTの議論は、しばらくの間盛んに行われ、Duane氏はこのように述べた。

PUTはSQLの言葉のINSERTと同等であり、POSTはCREATEと同じだと言う人もいます。これはある意味本当ですが、現実世界では、両方の操作の物理的なバイトは、リソースの既存コピーを上書きします。実際には、CRUDの言葉でUPDATEです。

そして、注目すべきなのは、RESTfulと呼ばれるためにPUTはサポートされていなければならないものではありません。最後に、オリジナルの記事で挙がったクッキーの問題があります。Stefan Tilkov氏はRESTのアンチパターンについて議論しました。少なくとも注意深く使われていない時、クッキーはその中の1つでした。

クッキーは、何かがRESTfulではない確かな印です。そうでしょう? いいえ。必ずしもそうではありません。RESTの重要な考え方の1つは、状態がないことです。サーバがデータを保存できないという意味ではなく、リソース状態かクライアント状態であれば問題ありません。拡張性、信頼性、そして、連結の理由で許されないのはセッション状態です。クッキーのもっとも典型的な使い方は、メモリ内に保存されたサーバサイドデータ構造とリンクするキーを保存することです。つまり、各要求にした従って、ブラウザの渡すクッキーが、会話形式かセッションの状態を構築するのに使われるということです。クッキーが認証トークンなどセッション状態に頼ることなく、サーバで認証できるような情報を保存するのに使われる場合、クッキーは完全にRESTfulです。ただ1つ補足することがあります。クッキーは、例えば、URIで標準ヘッダや、珍しいケースではメッセージ本体の中などの他のもっと標準化された手段で伝達できる情報をエンコードするのに使うべきではありません。例えば、RESTful HTTPの視点からHTTP認証を使うことが望ましいでしょう。

結論として、Duane氏は SOA と REST は一緒に使うと良いことが多いと述べた他の人たちに同意する。 さらに、Flashのアーキテクチャは、REST とSOAの中心原則であるというのは本当であり、機能的にふさわしいレベルをサポートするランタイムがあればよいのだ。言い換えれば、FlashでRESTfulなサービスを開発できるはずなのだ。