Railsチュートリアル12章のルーティングは複雑
Railsチュートリアル12章では、パスワードの再設定を行う
1.メールアドレス送信画面(パスワード再設定を行いたいユーザのメールアドレス)を表示する
2.メールアドレス送信画面でメールアドレスを送信する
3.パスワード再設定画面を表示する
4.メールアドレス送信画面で新しいパスワードを送信する
というざっくりと、4つの操作がある
4つの操作、4つのURL
| HTTPリクエスト | URL | Action | 名前付きルート |
|---|---|---|---|
| GET | /password_resets/new | new | new_password_reset_path |
| POST | /password_resets | create | password_resets_path |
| GET | /password_resets/<token>/edit | edit | edit_password_reset_url(token) |
| PATCH | /password_resets/<token> | update | password_reset_url(token) |
上記の1～4の操作に対応して、4つのURLルーティングが用いられる
ここで混乱したのは主に
・11章(ユーザーの有効化)ではAction:editで登録動作を行っていた点
・new create /edit updateがモデルの異なる値を更新する点
であった
11章はAction:editで登録を行った理由
これは、11章のユーザーの有効化においてはユーザーが何らかの値を送信する必要がないため(今回でいうところのメールアドレスやパスワード)
Getでの送信で登録を行うセキュリティ上の危険性はトークンとダイジェストによる認証で安全性を担保しているのでeditにてそのままDBの値を書き換えている
裏を返すと、12章での処理はユーザーがメールアドレスを送信する、パスワードを送信するという動作が入るためにcreateとupdateが必要となる
new create /edit updateがモデルの異なる値を更新する点の整理
URLルーティングごとにどういった処理を行うかは設計の問題
URLルーティングが先にあって、それに合わせて処理を行う形ではなく
先にあるのは処理で処理に対してURLルーティングが割り当たる
12章でいえば、上記1-4の処理をしなくてはいけないので
今回は画面の新規表示はnew、表示した画面からのPostはCreateを割り当てただけの話であり
例えば、ユーザーを新規作成する場合はユーザーの新規作成画面がnew、画面からのPostがCreateとなる
「ユーザーのメールアドレス再設定」という概念に対して、new /create edit/ updateを割り当てているとも考えられる
new/createにて「ユーザーのメールアドレス再設定」を作成して、edit/ updateにて「ユーザーのメールアドレス再設定」を編集してパスワードを再設定する
と考えられる