確認画面問題とリソースモデリング - 烏賊様

この条件での確認画面問題は，トランザクションリソースを導入しなくても，もっとシンプルに考えて解決できると思います． 処理内容：ユーザ名とパスワードが入力項目となるユーザ登録処理 画面遷移：登録画面→確認画面→結果画面 確認画面問題はトランザクションリソースの導入で解決できるのでは - 岩本隆史の日記帳（アーカイブ） まず上記の条件から次の事が言えると思います． ユーザ登録処理とはユーザリソースの作成処理と考えられる 画面はあくまでリソース状態が表示されるものなので，画面遷移とはユーザリソースの状態を都度表示しているもの ということで，あくまでユーザリソースとそれに対する CRUD（この場合は DELETE はないが）として考えればいいかな，と． まず最初の登録画面はユーザ作成フォームリソースを取得します． GET /users/new登録画面から確認画面のところはユーザリソースの新規作成と

[teppeis]

本当にdraftやトランザクションをリソースとして制御する必要があるならいいけど、たいていはalert確認の延長に過ぎないのでは。だとすればURLを与えずにフロントで処理すればいいと思う。

[tinsep19]

/users/newにパラメータ付きでGETするとそれが入力された状態で取得できるんじゃないかな。で、draftがあれば確認画面。その内容を/users/にPOSTして作成。/users/にPOSTしてドラフト状態のユーザーリソースはおかしい気がする。

[rochefort]

とても面白いが、DBに食わしたくないなぁ

[willnet]

draft=yesとかで確認画面かどうかを判断する

[naoyes]

確認画面

[studio-m]

確認画面でdraft=yesとしてPOSTしてcreateと処理する。完了時はdraft=noとしてPUTする。実装と合わせて考えると（そういう考えがREST的には間違ってるのかも知れないけど）悩ましい

[dann]

REST+認証

[yzatkatamayu]

ユーザ登録

[nak2k]

DB的にはdraft userは分離したいなぁ（状態のクラス化

[hiyang]

確認画面 ドラフト状態のリソース

[kdaiba]

RESTで認証

[yohei]

一つの解