The RESTというタイトルで今なお継続されている一連(リンク)の投稿メッセージで、Duncan Cragg氏は「eBayの件が真のRESTアプローチを統合APIに導入することを主張している」。「Business conversations(リンク)」の中で、Duncan氏は REST型のアーキテクチャを導入するためのビジネスケースを作成している。
対話形式でDuncan氏は、架空のeBayのアーキテクトに対し、RESTfulアプローチはますます単純であるが、WS-* スペックを使用したSOAビルドよりビジネスプロセスを構築するほうが一層パワフルであると説明する。アプリケーションアーキテクトの役割に関して、以下のように語る。
アプリケーションレベルでリソースの対話を設計することは、アーキテクトの仕事であるが、リソース型やビジネスレベルもそうである。もしくは、ビジネスロ ジックがおこなう、既存のリソースタイプや「resource-animating」コードを使用しているかもしれない。WS-*のみであると、この作業に暗い影を落とし、複雑にする。
「アクションではなくリソースの観点からとらえると、ずっと明瞭になる」とDuncan氏が、リソース指向アーキテクチャ(ROA)のサービスディスカバ リーおよび記述、クライアント状態およびセッションとビジネスプロセスといった側面の取り掛かる際に述べている。以下のように語る。
緩い取り決めや協定から始め、制約、契約やCentral Controlを必要な箇所のみに追加するのが、最善である。中央管理は、スキーマのみに対するものにする。
Enterpriseを「mashable」にすれば、多くの人の役に立つ。データのUUIDおよびGUIDをURLで公開する。標準コンテンツタイプで、データを変換し、濃縮する。
そうしたアーキテクチャでクライアント状態を管理することについて、以下のように注意をしている。
あらゆる隠し状態は、赤旗である。URIで、ステートフルなことを公表している限り、正しい方向に向いているということを知っている。[…]セッションや cookieで状態を隠していたり、no-cacheを設定することで同一のURIからそのクライアント専用のデータを返したりしていることが分かった り、セッションを通して連続する対話を結びつけている場合、誤った方向に向かっている。
そうしたアプローチは、企業では受け入れるのが困難な提案 であることを認めているが「ビジネスが稼動し、相互運用する方法の現実に、さらに近くマップする」ことを述べている。
REST […] は自然と宣言型ビジネスルールにマップする。プロセスの考えからリソースの考えに遷移すると、命令の考えから宣言の考えに遷移する。ハンドコーディングさ れたインターフェイスから別のものへ、データをインポートしたり、エクスポートしたりする調整をする代わりに、それを関連付け、多くの人がデータを修飾参 照したり、認識することができる。
企業におけるRESTful型の導入の経験を共有したり、オリジナルの掲載記事(リンク)やシリーズ(リンク)を確認するようにしたい。
原文はこちらです：http://www.infoq.com/news/2008/12/restful-business-conversations