Webアプリの画面はRESTfulなAPIの一クライアントにすぎない？
いつも思いつきで恐縮ですが、「Webアプリの画面はRESTfulなAPIの一クライアントにすぎない」んじゃないかと考え始めています。
ひらめいたのは、Rails2.0のルーティングを調べていたとき。scaffoldを使うと、下記のようなルーティングになるらしい。
| アクション | メソッド | URL例 |
|---|---|---|
| 一覧画面 | GET | /bookmarks |
| 登録画面 | GET | /bookmarks/new |
| 登録処理 | POST | /bookmarks |
| 参照画面 | GET | /bookmarks/1 |
| 編集画面 | GET | /bookmarks/1/edit |
| 更新処理 | PUT | /bookmarks/1 |
| 削除処理 | DELETE | /bookmarks/1 |
このうち、登録画面と編集画面に違和感を覚え、はたと気づきました。一覧画面や参照画面がリソースの素直な表現であるのに対し、登録画面と編集画面はPOSTやPUTのためにやむなく用意されたフォームでしかないことに！ 残りの5つでRESTfulなAPIが必要十分に表現できてしまうじゃないか！
AtomPubがまさにこれだ。登録画面や編集画面は、これらの操作を行いやすくするための「がわ」に過ぎない。
もっといえば、一覧画面や参照画面は、GETの結果（AtomやJSONやXMLだったりする）を人間に理解しやすい形式（HTML等）に変換した結果とみなせるし、更新処理や削除処理の結果メッセージについても同じだ。
すべて一緒くたに考えるからややこしくなるのだ。まずはRESTfulなAPIだけ作る。その後、それを利用する画面（クライアント）を作っていく。画面については、無理にRESTfulにしようと考えない（デスクトップアプリをRESTfulにしようなんて思わないのと同じ）。たとえば確認画面なんて、RESTfulにする意味はない。APIを呼び出す前の話なんだから。
というようなことをつらつら考えた、というお話でした。Twitter上での下記発言に刺激された感じです。
昨今では、RESTful/ROAにしなきゃという強迫観念がいろいろなところに見受けられます。一時期のOOA/OODやUMLみたいに。またも手段が目的化されているのではないでしょうか。
Takuto Wada on Twitter: "昨今では、RESTful/ROAにしなきゃという強迫観念がいろいろなところに見受けられます。一時期のOOA/OODやUMLみたいに。またも手段が目的化されているのではないでしょうか。"
やはり今年のテーマは Web サービスと Web アプリケーションのギャップを埋めることだな。
TAKAHASHI Kunihiko on Twitter: "やはり今年のテーマは Web サービスと Web アプリケーションのギャップを埋めることだな。"
RESTful/ROA 至上主義ではなく、このきれいな世界をいったんきちんと把握したうえで、現場でなにができるかを考えたい
TAKAHASHI Kunihiko on Twitter: "RESTful/ROA 至上主義ではなく、このきれいな世界をいったんきちんと把握したうえで、現場でなにができるかを考えたい"
