RESTとその他のアプローチ(特にWebサービス)の利点の比較、もしくはもっと単純にRESTをWebベースのインテグレーションで利用する利点に関して、長い間、議論されてきた。議論は続いているが、他の領域では当然と思われていて、REST、特にREST/HTTPに欠けている機能があるのかどうかという点を、一部の人は議論の対象にしようとしている。それらのうちの一つに、分散トランザクションがある。Bill Burke氏がRESTeasyに実装した内容を示し、コメントを求めたことから始まった、REST-discussion メーリングリストでのやりとりがあった。
素晴らしくきれいなAPIです。私はシステムによって公開されるURIの数を減らし、システム全体の柔軟性を高めるために、AtomのLinkで、発行されるURI schemeのいくつかを置き換えられないかを知りたいと思っています。また、データフォーマットではなくLinkの関係性を標準化すればDTX標準で標準のデータフォーマットを定義しなくてよくなるのではないかと考えています。
最初は、ACIDトランザクションと補正ベースのトランザクションのどちらが必要かという活発な議論から始まった。(元Choreology社でOASIS BTPの)Bob Haugen氏は次のように指摘している。
基本的なところは次のようなところです。1. 最初のフェーズで、全ての参加者は、それぞれのリソースを一時的に更新します(ステートを変更するか、一時的な別のリソースを変更します)。2. コミットのタイミングで、全ての参加者は、リソースを最終状態に更新します(もしくは最終状態を示すリソースを作成します)。3. アボートやキャンセルが発行されたタイミングで、全ての参加者は一時的なリソースを削除する、もしくはキャンセル済みとマークします。このパターンは。選択的なコミットやキャンセルも許します。例としては入札プロセスのようなものです。
もしトランザクションが必要なのであれば、Webサービスに関する理由と同じ理由から、ある種の拡張トランザクション(補正が特徴的な例だ)がとるべき手段だとという点では合意されているようだ。Mike Amundsen氏は、次のように付け加えた。
私は、Saga(ロングトランザクション)モデルを使うのを好みます。なぜならこれが楽観的パターンで、HTTP上で設計しやすいことに気がついたからです。よりプログラム的な観点からいうと、初めのインタラクションを、一連のやりとり(前方補正か後方補正で実装)を気にすることなく設計することができます。それによって、補正処理を実装プロセスの後の方で(時によっては数週間もしくは数ヶ月後に！)クライアントやプロキシなどに大きな混乱を与えること無しに付け加えることが可能になります。
しばらくして、Roy Fielding氏が議論に参加した。彼は数年前には、こう言っていた...。
この話題はwebdavとhttp-wgメーリングリストで数度取り上げられています。トランザクションはリソースです。しかし要求リソースとトランザクションの関係は、ヘッダフィールドによって実現され、そのヘッダでは、それぞれのリクエストが、階層をもったトランザクションの中の一連のリソースとして定義されています。他の言葉で表現すると、トランザクションを開始するのにサーバーに依頼し、それぞれのクライアントにリクエスト毎にリクエスト番号を付与したURLを与え、そのURIを送信し、トランザクションURIに最終的なリクエストを送り、トランザクションをアボート、もしくはコミットします。これは基本的には、まだ実態のないWakaプロトコルのために私がやったことです。
しかし数年で、経験に基づき、Roy氏は意見を変えた。
もし分散トランザクションプロトコルを必要としているとすると、どうしてそのアーキテクチャがRESTに基づいているといえるのでしょう。一つの状況(クライアントでは、RESTfulなアプリケーションのステートを使い、ハイパーメディアによってステートの遷移を定義する)から、クライアントがサーバーに自分のリソースをどのように管理しているかを伝えないとならず、トランザクションのセマンティックを分散環境で合意しなければならないような状況にどうやって移れるのかわたしにはわかりません。おそらくは、あなたが考えているシステムは、複数のサーバーでCRUD操作を行うというようなものでしょう。それぞれのアクションは、RESTFulなアークテクチャに基づいてるかもしれません。それら全てが実行されて、クライアントが変更を承認またはキャンセルをする最終リクエストを投げる時に、TM(Transaction Manager)スタイルのマネージャリソースとやりとりするかもしれないでしょう。そのマネージャリソースは、他のサービス全てに関連する変更をコミットするように複数の永続的リソースに依頼します。ちょうど、ステージングサーバが公開前の準備中のコンテントを保持するようまものです。これらのアクションをあわせてみるとACIDトランザクションと同等のものです。これらのことは全くRESTクライアントには重要でではありません。クライアントに関して言えば、非同期に複数の呼び出しがオーバーラップしているとしても、一度に一つのリソースとやりとりしているだけです。リソースセマンティック(ここでは気にしない別のアークテクチャ)に従ってバックエンドに実装された仕組みは置いておいて、それ以外にトランザクションプロトコルは存在しません。クライアントにとってアプリケーションの各ポイントで様々な選択肢の表現が与えられるだけで、トランザクションプロトコルというものはありません。クライアントサイドでトランザクション・プロトコルに関する合意は必要ありません。なぜならクライアントは、サーバから与えられて選択肢から選択することができるだけだからです。
これには、多くの反応があった。(ACIDでない)トランザクションプロトコルの拡張の利用例で、投稿者がRESTFulの流儀だと信じているようなものなども投稿された。しかし、Bull Bruke氏は、これは、もともとの投稿の真のポイントではないと意見述べた。
私が元々の投稿で意図していたのは、リンクの関係を定義し標準化することで、クライアント・リソースのレベルでも、リソースとTM(トランザクション・マネージャ)のやりとりも、物事がずっと単純になるかもしれないということでした。
メーリングリストの何人かは、これに共感したようだ。実際、Alexandros Marinos氏は、彼が同僚と実装してきた(ACIDベース)プロトコルを紹介した。議論は続いているが、(拡張)トランザクションがRESTの世界に適するかどうかの明確な答えは出ていないようにに見える。しかし、多くの人が様々な理由でトランザクションが必要だと信じていることは間違いないようだ。