Ajax中心に考えたときのURIとWebページ中心に考えた時のURIは違わないか

たとえば、何かいい品物を一覧から注文する、みたいなふぉーむを扱うためのアクションがあるとして、

stores/:store_id/orders/(GET)(入力フォーム)
=> stores/:store_id/orders/confirm(GET)
=> stores/:store_id/orders/confirm(POST)
=> stores/:store_id/orders/:id/done(GET)

というのもあるけど、

stores/:store_id/orders/new(GET)(入力フォーム)
=> stores/:store_id/orders/new/items(POST)
=> stores/:store_id/orders/new/items(GET)
=> stores/:store_id/orders(POST)
=> stores/:store_id/orders/:id/close(GET)
=> stores/orders/:id(GET)

の方が好きなので理由を考えてみる。

実利的には、多分indexというのは、そのフォームの入力の結果、作成されたものの一覧を見たいってのと、後者は、ユーザーがそのアクションにリクエストをしながら行う操作で作成されるもの中心になっている気がして好き。

入力フォームを通して作られるのは注文だから、入力フォームで注文するときに便利なので注文フォームの一覧が並んでいるとしても、注文から見ると、その画面の役割はnewアクションのそれにあたる気がする。

だけど、本当は住所入力、とか色々あるので、

stores/:store_id/orders/new/items(GET)(入力フォーム:品物一覧)
=> stores/:store_id/orders/new/items/confirm(POST)(入力フォーム:品物一覧確認)
=> stores/:store_id/orders/new/addresses(GET)(入力フォーム:アドレス一覧
     (新規フォームとこれまでに入力した住所がある感じ, 追加、選択は以下のAjaxかも))
     stores/:store_id/orders/new/addresses#new(GET)(新規入力フォーム開く)
     stores/:store_id/orders/new/addresses#create(PUT)(住所一覧追加)
     stores/:store_id/orders/new/addresses#:id/edit(GET)(住所修正欄に切り替え)
     stores/:store_id/orders/new/addresses#:id(PATCH)(住所修正欄から戻して、住所更新)
     stores/:store_id/orders/new/addresses#:id(DELETE)(住所一覧から削除)
=> stores/:store_id/orders/new/addresses(POST)
=> stores/:store_id/orders/new/payment_methods(GET)(入力フォーム:支払い方法一覧)
     (新規フォームとこれまでに入力した支払い方法一覧がある感じ, 追加、選択は以下のAjaxかも))
     stores/:store_id/orders/new/payment_methods#new(GET)(新規入力フォーム開く)
     stores/:store_id/orders/new/payment_methods#create(PUT)(支払い方法一覧追加)
     stores/:store_id/orders/new/payment_methods#:id/edit(GET)(支払い方法修正欄に切り替え)
     stores/:store_id/orders/new/payment_methods#:id(PATCH)(支払い方法修正欄から戻して、支払い方法更新)
     stores/:store_id/orders/new/payment_methods#:id(DELETE)(支払い方法一覧から削除)
=> stores/:store_id/orders/new/payment_methods(POST)
=> stores/:store_id/orders/confirm(GET)
     いままでの情報はcookieか何かに登録されている.
     今までの入力した情報が表示されている感じ.
     これまでのフォーム画面に対してリンク等がある.
=> stores/:store_id/orders(PUT)
=> stores/:store_id/orders/:id/close(GET) => stores/orders/:id(GET)

ここまで書いて、ユーザの操作によって何が作られるか、リソース中心にURIが設計されているか、という点とURI + リクエストメソッドの組み合わせにフレームワークのアクションが1:1かみたいな事が混ざっている気がした。

基本的にjsでバリデーションするので、confirm/validateは役割が違うのでアクションは分けて設計するといいのじゃないかなー、という気がしたけど、

うまく答えが見つからない。

とりあえず後者が好きなのは、私は基本的にjsでバリデーションの表示を作ってきたからだと思う。

jsのフレームワークでvalidateオプションに渡すものと、実際にアラート等を出す処理は別だよ! みたいな感じ。

http://qiita.com/irxground/items/cd83786b10d81eecce77 を見て、なるほどう、と言いかけたけど、これは違うような。。

http://d.hatena.ne.jp/tkawa/20110627/p1 途中の値の保存はセッションかクッキーで、と思ったけどトランザクションを使うこともあり得そう。。

今度、応え合わせというわけじゃないけど、Amazon先生で買い物するとき眺めてみよう。。

とりあえず、Ajaxでは、クライアント側の分のバリデーションおよび表示は基本的にクライアント側でやって、最終的にもしサーバー側で保存に失敗したときは、サーバー側から値は合ってるはずなのに失敗した~って言われるイメージで作っているから、確認画面が要らない場合があるんですよね。

WEBページではそうもいかないから、確認画面等を設ける事になるので、 URLはなんか違って来るのかなー、というお話。

一時的に確認書を作るという意味で、 /orders/new/confirmation(POST) => /orders/new/confirmation(GET) はありかもしれない。

けどアクションは二つは分けたいな...。

orders_new_confirmation#create => 'orders_new_confirmation#show'

みたいな...。

woshidan's loose leaf

ぼんやり勉強しています

Ajax中心に考えたときのURIとWebページ中心に考えた時のURIは違わないか