Duncan Cragg氏が完全なGETベースのREST統合の考え/パターンを説明する。このパターンは、MicrosoftのFeedSynの仕様の考え方と非常に似ていることが分かっている。Cragg氏は、エンタープライズアーキテクトとの仮説に基づく会話を用いてこのパターンを説明する。
いろいろ悩んだエンタープライズアーキテクトは、そのようなサービス指向に基づいてRESTが実践されていることに気付きました。ウェブサイトには「REST API」があり、「ウェブサービス」は複数あります。AtomPubでさえ、「サービスドキュメント」があります! AtomPubのようなパターンは、完全なHTTPメソッド一式を通して、単なるread/writeデータサービスを提供しました。このようなread/writeインターフェースは、もっと複雑なサービス機能の周りでラッパーとして使われていました。
「REST統合の中でウェブはどこに位置するのでしょうか? ウェブは、PUTとDELETEがなくてもうまく動きます。RESTfulなところでGETを使えば十分ではないでしょうか?」とそのアーキテクトは思いました。
Cragg氏はGETベースの統合パターンをFORESTと呼ぶ。彼の説明によると、FORESTはRESTfulなオブザーバー同期パターンだ。
FORESTは、GETだけを使うREST統合パターンであり、単に次のように定義されます。リソースの状態は、リンクしている他のリソースの状態によって決まります。 [...] つまり、これらの依存関係を見るために、リソースサーバーは、クライアントにもなるべきです。
Cragg氏は続けて、マッシュアップを含むそのような統合の例を2、3挙げた…
FORESTは、GETだけから派生した、または、ウェブユースケースに呼び掛けるRESTパターンです。これには、フィードの集合やフィルタ、他のウェブページのサマリを作成するサイトのような特定のマッシュアップが含まれます。
… そして、エンタープライズと関連性がある。
FORESTは、ROA / WOA / SOAで「エンタープライズマッシュアップ」を構築するRESTパターンです。 [...] エンタープライズ・マッシュアップ言語は、私が知っているこれにもっとも近いものです。しかし、FORESTはまったく違います。もっと簡単で、ただRESTパターンだというだけです。
そのため、ATOM/RSSフィードのGETベースの同期化の考え方は、Microsoftのフィードの仕様であるFeedSyncとしてすでに知られている。
AtomやRSSのFeedSyncの目指すものは、アイテム共有の基礎としてAtomとRSSフィードを使うために、ゆるく協力するアプリケーションを可能にするのに必要な最小限の拡張を定義することです。 – つまり、2つ以上のフィードがお互いに購読しあう中で新しく変化したアイテムの双方向の非同期な同期化です。
これは、一般的に標準データモデルであるリソース表示がフィードとして表され、エンドポイントはプル型の同期を使うことができる統合の形だ。これらのエンドポイントはデバイス、サービス、アプリケーションなどGETセマンティクスを使ってHTTPを通してリソースの状態を同期化できるという考えにより、このパターンは様々な形でさらに多くの場所で使われることになるだろう。