1207639843**[PHP][REST]PHPでRest開発、如いては、簡潔で迅速なWebアプリケーション開発

Pageベースでの開発
Page＝URIの一対一はRest的には、無理

URI＝Resourceの一対一にRestだとなる

Resourceって何？
GetとかPostとかのメソッドを持ったオブジェクト

後、ディレクトリとして呼ばれた際のメソッドも持っといた方が
便利な気がする

また、Uriの動的なパラメータの数とかパラメータとして取得する際の変数名もディレクトリとして呼ぶ際に必要かな

Resourceの認識はコノ程度の認識でイイヤ。

だと最小構成だと

Resource、Page、Dao

になるのかな

んで、最低限やるべき事

Uriとリソースオブジェクトのマッピング
（取りあえず、ここらへんを考えていてもわからなかったから
（書いてみた。
（んでPHPとしての問題が凄い出てくる。
（リソースをコンテナにアホみたいに突っ込むと
（使ってもいないリソースがアホみたいに出来る
（リソースの生成タイミングを遅延評価にしないとダメだなぁ

リソースオブジェクトとページオブジェクトのマッピング

んー微妙。基本的には、Webアプリケーションとしては
ページオブジェクトみたいな物の方が楽

でもRestでごにょごにょやるのに邪魔。
ってかページじゃない物も多いし

ページな時も在るし

PRGパターンとかREST的なURIの際にはどーなるんだろう
って思ったら

むしろRestの方がURIが少ない

/message/input
/message/confirm
/message/complete

とかって

GET /message
POST /message ドラフトデータ
POST /message 本物データ

だから、そもそもPOSTでレスポンスをそのまま
返してもPRGとか関係なくURIは一意だしなぁ

普通にhiddenと入力フォームの形で
データを返せるし

だけども。

状態によって返すリソースが変わるから
状態遷移の扱いを如何するかな

結局ドラフトか如何かをチェックしてって形は
微妙な気もする

それは、それでPOSTのメソッドオーバーライドじゃないかなぁ

それこそ、method confirm が存在するっぽい感じだ
でも、ソレを外部に現してないから、コレはコレでOK
なのかな？

んー、URI層とプレゼンテーション層の境目の
インピーダンスミスマッチの解消方法が判らないなぁ

プレゼンテーションのレイヤの一段上に
URIとPOSTなどのパラメータによりプレゼンテーションへ
繋ぐ為のレイヤが必要で
（そもそも、ココのレイヤか如何かも
（間違っているかも知れないけれども

どうするかなぁ

ココのところは、所詮何パターンかに集約されるのかな？
だったらDxo的な物として扱えたりするのかなぁ