Resource-oriented designはHTTPの形ではなくAPIの語彙をResourceとMethodで整理する
Resource-oriented design は、単に「URLを名詞にしてHTTP verbを使う」ことではない。Google AIP-121 は、APIの基本要素を 個別に名前を持つResource、その関係・階層、少数の標準Method として整理している。さらにAIP-130は、Methodを「serviceがconsumerのために実行できる特定のoperation」と定義する。
この見方は、中規模のApplication Architectureを考えるときに重要になる。小規模なWebアプリではHTTP route自体をApplicationの語彙としても大きな問題にならない。しかし外部入口がRESTだけでなくMCP、Job、CLI、内部呼び出しへ増えると、POST /projects/:id/archive のようなHTTP表現と「ProjectをArchiveする」というApplicationのCapabilityを同一視する理由は弱くなる。
そこでResource-oriented designから借りるべきなのはHTTPそのものより、ResourceとOperationを先に定義し、その外側へTransport mappingを置くという考え方だと捉えられる。Google AIP自身もcustom methodを認めており、無理にCRUDへ押し込むことを推奨していない。OperationはTransportから独立したApplication Capabilityとして置ける と RESTは捨てるのではなくApplication CoreからAdapterへ降格させる はこの分離を掘り下げる。
一方で、Resource-oriented designをDomain modeling全体へ拡張しすぎるべきでもない。Workflow、計算、集約検索など、永続的Resourceとして表すと不自然なCapabilityもある。AIP-136もresource-based、collection-basedだけでなくstateless methodを認めている。Resourceは有力なAPI vocabularyだが、Applicationの全意味論をResource treeへ還元する原理ではない。