Dhananjay Nene氏は以前RESTの歴史について記録した記事を書いたことがあるが、今度はサーバサイドのリソース指向フレームワーク（ROF=Resource Oriented Framework）を設計する際に期待されるべきいろいろな特徴について検討している。この記事はアプリケーションの細かい粒度のオブジェクトモデルとそのリソースモデルとの関係についてもとらえようと試みている。
Dhananjay氏によれば、Struts、Django、Ruby on Rails などのフレームワークが人気であることの結果として、かなりの数の特徴が当たり前のもののように考えられている。しかしながら、それらをはっきりと列挙してみることで、このようなリソース指向フレームワークがなぜ成功し、人気あるものとなったかを示す特徴を明らかにするのに役立つ。Dhananjay氏が見つけたROFのこれらの特徴の例は以下のようなものである。
ROFはリソースを端点として表現するような抽象を持つ
仮に、私がオーダー（Order）をリソースとして利用し、オーダーコントローラ（OrderController）に承認メソッドを導入したとしたら、この要請とは一貫していない。そのためには、オーダー承認（OrderApproval）リソースとしてモデル化される必要があり、それは、正常終了時には、オーダーリソースの状態を‘承認済み’に変更する効果があるものである必要があるだろう。
一貫したリソース操作が期待できるような場合には、その操作は自動的かつ魔法のように実際に実装される
ROFはライフサイクルにおける標準的な局面（例えば、検証）も追加的にサポートする
リソースインターフェースメソッドはフレームワークによって暗黙的に実装され［、さらに、］フレームワークによって開発者が独自の実装をプラグインしたり、オーバーライドしたりすることが出来るようになる［だけでなく、例えば検証のようなライフサイクルでの作業もサポートすることが出来るようになる］。
ROFは開発者がPUT、POST、DELETEの下流での影響を取り扱えるように、メソッドをオーバーライドしたり登録したりすることができる方法を提供する
私は以前RESTベースのシステムがDBMSと同様であるという類似性について記事を書いたが、そこではクライアントアプリケーションはテーブル（RESTの場合にはリソースにあたる）に対してSELECT、INSERT、UPDATE、DELETEなどのSQL（HTTP/RESTではGET、PUT、POST、DELETE）を直接実行することが出来、ビジネスロジックはトリガーとして実装される、と書いた。このようにフレームワークは開発者がこれらのトリガーを定義することができるものでなければいけない。
ROFは実際のプログラムの構成をリソースの抽象として表現したり、対応づけたりするメカニズムを提供する
これを実現する方法はたくさんある。XML、YAML、DSL、Annotation - 好きなものを選べばよい。加えて、実際のクラスは（POJOの場合と同様に）定義されリソースの特徴はそれに対応づけられるか、そうでないなら、クラスはメタデータを使ったメタプログラミングに基づいて実行時に現れることになる。そのために、フレームワークにおいて［オブジェクトモデルの］関連が表現され、イントロスペクションされたりすることが出来るようになっている。
ROFはURIで表現されたリソースをまたぐ外部キーが基本的なビジネスオブジェクトへの参照に対応づけられるようすることができる
リソースはURIを通してお互いに参照する。基本的なビジネスオブジェクトはオブジェクト参照を通してお互いを参照する。リソースの記述とURIへの対応づけが与えられたとき、フレームワークはそのURIとオブジェクト参照との間の透過的な参照／逆参照を可能にすべきである。
列挙されたROFの側面の多くはRESTfulサービスにとって当然のことのように見えるが、いくつかの特徴はより深い説明や調査を必要としているように思う。もしかすると、具体的な例を使って推敲することが必要なだけかもしれないが。
ROFは他のリソース／ビジネスオブジェクトの位置を配置するファクトリメソッドを利用可能にするか、またはそれらのインジェクションを利用可能にする
開発者は、これらのものとの相互作用を粗い粒度の（リソース）レベルで行うか、細かい粒度の（ビジネスオブジェクト）レベルで行うかを選択することがあるだろう。フレームワークはこのような開発者の活動に必要なサポートを提供すべきである。
ROFは、リソース／メディアタイプに関する記述をリソース表現に含めて送ることが出来るようにすべきである
RESTではメディアタイプは自動的に発見され、自己記述的であることが可能であるので、フレームワークもこのようなメディアタイプに関するメタデータをクライアントに提供することができるようにすべきである。実際のメタデータはRDFa、XML Schemaのスニペットなどのような代表的な標準のいずれかを適切に利用して表現することになるだろう。
Dhananjay氏が列挙した事柄はかなり包括的なものであるが、記事では、例えば、モニタリング、監査／ログ、トランザクション管理、オブジェクトプーリングのサポートといったいくつかの非機能要件については述べていない。詳細については元記事を必ず読むようにして欲しい。