PRGパターン

etc

別にロールプレイングゲームじゃないです。
Webアプリケーションの実装方式のお話。


例えば、


入力画面→確認画面→完了画面


って感じで画面遷移していったとして。
完了画面でF5を押したらどうなるか？
⇒データベースに更新しに行く処理が2回流れて欲しくない。


例えば、


POSTで画面遷移→ブラウザの戻るボタン


ってオペレーションしたらどうなるか？
⇒ページの有効期限切れってなって欲しくない。


んで、このPRGパターン。


1. ブラウザ→POST→サーバ
⇒ブラウザからサーバにPOSTでデータを送って、
　サーバ側ではそのデータを元に処理をする。


2. サーバ→REDIRECT→ブラウザ
⇒サーバからは転送先のアドレスと、
　302のレスポンスコード(転送だよってのを示す。404だとNot Found。500だとサーバーエラー)を返す。


3. ブラウザ→GET→サーバ
⇒ブラウザからは2.で指定されたアドレスにリクエストする。


で、どうなるかっていうと、、、


上の完了画面でF5を押された〜っていう場合
→3.だけが呼び出されるのでDBに更新に行くような処理(1.のような処理)が
　何度も呼び出される心配がない。


上の戻るボタンが押された〜っていう場合
→GETの場合は"有効期限が切れました"ってことにはなりません。
　通常GETの場合は、リクエストするURLに XXX=hoge&XXXX=hage って感じで、
　リクエストされる情報がURL上に記述されている形になるため。
　リクエストパラメーターってのは、、、っていう場合は、
　HTTPセッションを使って、そっから取得する感じ。


この辺をフレームワークで隠蔽して、プログラマはあんまり考えなくてもいいように、、、、
うちの会社でも、どこの会社でも、たぶんそんな感じ。


なんで、こんなエントリを書いたかっていうと。
実はリダイレクトの仕掛けってよくわかってなかった。


Strutsのredirect使うと、そういう風に動くから。別に意識してなかった。
サーバー側でヨロシク処理してるのかと思ってた。


システムテストの時に、障害があって、Apacheのログ眺めてたときに。
"あっ、そういうことなんだ"って。


他にも、こういうのいっぱいあるんだろうなぁって。
フレームワークうんぬん語るのもいいけど、
こういうところをちゃんとおさえなきゃなって思います。


Teeda使ってみたいなぁ↓。
http://event.seasarfoundation.org/sc2007spring/viewAttachment.do?_pageName_=Session&_fileName_=sc2007spring_S4_Teeda.pdf