確認画面問題とリソースモデリング

rest

この条件での確認画面問題は，トランザクションリソースを導入しなくても，もっとシンプルに考えて解決できると思います．

  • 処理内容：ユーザ名とパスワードが入力項目となるユーザ登録処理
  • 画面遷移：登録画面→確認画面→結果画面
確認画面問題はトランザクションリソースの導入で解決できるのでは - 岩本隆史の日記帳（アーカイブ）

まず上記の条件から次の事が言えると思います．

  • ユーザ登録処理とはユーザリソースの作成処理と考えられる
  • 画面はあくまでリソース状態が表示されるものなので，画面遷移とはユーザリソースの状態を都度表示しているもの

ということで，あくまでユーザリソースとそれに対する CRUD（この場合は DELETE はないが）として考えればいいかな，と．

まず最初の登録画面はユーザ作成フォームリソースを取得します．

GET /users/new

登録画面から確認画面のところはユーザリソースの新規作成と考えればいいですが，注意すべきはユーザリソースをドラフト状態として作成する，というところです．

POST /users
    username=foo
    password=bar
    draft=yes

HTTP/1.1 201 Created
Location: /users/1

AtomPub を例にとって話しますが，AtomPub には app:draft 要素があって，これの値を yes にして POST するとサーバはドラフト状態としてリソースを作成するという仕組みがあります．なのでこれに対応するような形で考えるといいのではないかと思います．

確認画面というものをどう考えるかですが，これは draft=yes なリソース状態のユーザリソースを取得した場合の画面である，と考えればいいのではないでしょうか．確認画面を見て内容を変更したい場合は，ドラフト状態を維持したままで対象のユーザメンバリソースに修正内容を PUT します．

PUT /users/1
    username=baz
    password=bar
    draft=yes

HTTP/1.1 200 OK

修正結果の確認も終わりコミットするところは，draft=no として PUT します．

PUT /users/1
    username=baz
    password=bar
    draft=no

HTTP/1.1 200 OK

これでユーザ登録処理の確認画面を含む画面遷移を，ユーザリソースのリソース状態に注目して表現できると思います．

懸念事項として

  1. ユーザコレクションリソースを取得するときにどんなユーザメンバリソースを返せばいいか
  2. 登録処理の途中でドラフト状態のユーザリソースが放置されたらどうするのか

ということが考えられますが，1. に関しては draft=no なメンバリソース一覧を返すようにすれば問題ないですし，2. についてはあくまでサーバ側のポリシーとして解決する問題だと思うので，例えば「新規作成された時刻から 24 時間以上過ぎてもドラフト状態のリソース」は途中で投げ出されたものと見なし，バッチ処理で一括削除してしまうというのもアリだと思います．