Domain Model は饒舌に業務を表現しますが、必ずしもユーザーインターフェースに適したものとは言えません。プレゼンテーションの役に立たない情報を持っている場合もあれば、人に理解しやすい表現が足りていないこともあります。
Two Step View は、直接モデルをビューで視覚化する前に、いったんプレゼンテーションに適したデータモデルに変換するパターンです。モデルをページに表示するとき、「後はそのままテンプレートに流し込めばいいだけ」と言えるような形にしておくと、Template View での扱いがとても簡単になります。いちど、動的で有意な部分だけを集めた、論理的なページでのモデルビュー変換をするのです。
HTML などでユーザーインターフェースを作っているときは、レイアウトに意識が奪われています。そこに Domain Model の意味解釈をするプログラムを混ぜると、複数のことを同時に考えなければならなくなります。ロジックが難しくなりすぎると、不具合のリスクが高まります。つまり、賢すぎるビューの問題です。
似た問題に対応するパターンに Transform View があります。Transform View と Two Step View の違いは、扱うもののスコープです。Transform View はひとつのエンティティ単位といった、モデルの「部分」を扱います。その役目は Temoplate View の補佐です。テンプレート 1 に対して変換は 0 〜 N です。Two Step View が扱う単位は「ページ」、あるいは別の言い方をすると「URL が表すリソースプレゼンテーションの全て」です。テンプレートと変換を駆使したビューの前に、唯一の、間接的な論理ページ生成を挟むのです。
REST は (単なる CRUD API ではなく)、Representational State Transfer の略です。HAL あるいは HATEOAS を伴い、人にとって有意なデータと論理的なハイパーリンク選択肢を持つ Representational State は、Two Step View で言う論理ページにほかなりません。PoEAA 本が書かれた当時、REST は論文に初めて登場した頃で、本では XSLT などにたとえて説明されています。現代では、実質的に XSLT や SOAP といった当時のトレンドはみんな、JavaScript と親和性の高い、より大衆的な技術に取って代わられました。
REST は転送できる形式であることがポイントです。システム内部のプロセス間でやりとりする以外に、インターネットを通して、JavaScript で動くクライアントプログラムとも、スマートフォンアプリとも連携可能です。広い視点で言うと、それらは MVC のビューです。
HTML はブラウザでレンダリングしないと、どこに何が書いてあるのかがわかりにくく、レイアウトのせいで異様に長くもなります。コマンドラインから気軽に cURL でアクセスできるものではありません。いっぽう、論理ページとしての REST は多くの場合、JSON にシリアライズされます。cURL と jq を使って、Web ページの GUI と等価な情報を得ることができます。