いつも思いつきで恐縮ですが、「Webアプリの画面はRESTfulなAPIの一クライアントにすぎない」んじゃないかと考え始めています。 ひらめいたのは、Rails2.0のルーティングを調べていたとき。scaffoldを使うと、下記のようなルーティングになるらしい。 アクション メソッド URL例 一覧画面 GET /bookmarks 登録画面 GET /bookmarks/new 登録処理 POST /bookmarks 参照画面 GET /bookmarks/1 編集画面 GET /bookmarks/1/edit 更新処理 PUT /bookmarks/1 削除処理 DELETE /bookmarks/1 このうち、登録画面と編集画面に違和感を覚え、はたと気づきました。一覧画面や参照画面がリソースの素直な表現であるのに対し、登録画面と編集画面はPOSTやPUTのためにやむなく用意された
この条件での確認画面問題は，トランザクションリソースを導入しなくても，もっとシンプルに考えて解決できると思います． 処理内容：ユーザ名とパスワードが入力項目となるユーザ登録処理 画面遷移：登録画面→確認画面→結果画面 確認画面問題はトランザクションリソースの導入で解決できるのでは - 岩本隆史の日記帳（アーカイブ） まず上記の条件から次の事が言えると思います． ユーザ登録処理とはユーザリソースの作成処理と考えられる 画面はあくまでリソース状態が表示されるものなので，画面遷移とはユーザリソースの状態を都度表示しているもの ということで，あくまでユーザリソースとそれに対する CRUD（この場合は DELETE はないが）として考えればいいかな，と． まず最初の登録画面はユーザ作成フォームリソースを取得します． GET /users/new登録画面から確認画面のところはユーザリソースの新規作成と
REST勉強会、参加したかったなあ。知らなかった私が悪いんですが。 勉強会では「確認画面ってどう扱うの？」という議題が出たそうで、私なりに考えていた解をここに提示する次第です。 例示する処理 処理内容：ユーザ名とパスワードが入力項目となるユーザ登録処理 画面遷移：登録画面→確認画面→結果画面 1. トランザクションリソースの作成 クライアントは、登録画面から「トランザクションリソースのファクトリリソース」にユーザ名とパスワードをPOSTします（通信イメージは適当です）。 POST /newaccount-transactions HTTP/1.1 HOST: example.org username=iwamot password=hogehoge 妥当な入力なら、サーバはトランザクションリソースを作成し、そのURLを返します。これが確認画面となります。 HTTP/1.1 201 Crea
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
