Confirm画面のURL設計を見直す

現在開発中の某Webアプリなんですが、 「メディアに「プレス」してもらっても恥ずかしくないものを！」 という意気込みで作っています。今まで作ったものは、どれもこれも、やっつけ仕事で感があり。とてもとても、メディアに取り上げてもらえる代物でなかったからです。 一つ一つ調査しながら、割としっかりしたものを作ろうとしています。 そして、今年も行われるだろうMashup Awardsでプレゼンするのが目標です。入賞なんて、とんでもなく高い壁なので狙えませんが。 とりあえずやれるだけ、頑張ろう。

Confirm画面を作る

さて、やっつけ仕事でないようにするには、確認画面を作ろうとしていますが、 URLどうする？？ということで考え込んでしましたら、良さげなコンテンツを発見。 正しいURLについて inputで入力画面、comfirmで確認画面でいいのかぁ。なるほどね。 ということで、comfirmで作ってみよう。

で、どうすればいいのかまた頭を抱える

input,comfirm,completeを使えばいいとは分かったが これを実際に実装にもっていくにはどうするかと考えたら。 頭を抱えてしまった。で、ひねり出したURL設計はこれだ。 かなり自信がないけれど。 comfirmをPOSTするという設計はすっきりしていそう。

初回登録

• GET /book # 新規入力画面
• POST /book 　　 # 確認ボタン押下 303でcomfirmへリダイレクト
• GET /book/:id/comfirm
• POST /book/:id/comfirm #登録ボタンでPOST　303でcompleteへリダイレクト
• GET /book/:id/complete

次回編集させるときは

• GET /book/:id/input
• POST /book/:id/input 　　　# 確認ボタン押下 303でcomfirmへリダイレクト
• GET /book/:id/comfirm
• POST /book/:id/comfirm #登録ボタンでPOST　303でcompleteへリダイレクト！
• GET /book/:id/complete

確認画面まで行ってしまうと、IDが採番済みになってしまうという欠点はあるものの すっきりはするかな。GDGD言わず、これで実装していくか。

これだと、PUTはでてこないけど・・

REST における PUT メソッドと POST メソッドの違い 。やっぱりよく分からなくなってしまった。 REST APIと画面との関連が頭の中で、混然としてしまっているようです。 まぁ、動けばいいかぁ・・。結局やっつけに・・・