t_wada さんの議論のポイント
http://www.slideshare.net/t_wada/restful-web-design-review より。
やりたいこと vs. (Rails的な)作りやすさ
確認画面、プレビュー画面、完了画面…
リソースの移動、コピー
トランザクションの表現
-
複数レコードを選択して更新する UI
- 207 Multi-Status の誘惑
-
URLに機械採番の id が含まれる
- セキュアじゃ無い
- 永続的でない（かも）
-
APIのバージョニング
- 自前でやっていた
- https://github.com/bploetz/versionist 良さそう
rails4 の PATCH メソッドどうよ？
-
あまり非同期処理に頼らない
- DOM Scripting の原則に従う
-
RESTfulなサーバとリッチjsという設計に倒しすぎるとUXや保守性が低下する可能性があるので注意
- REST厨がみんな通る道
- 一方Twitterはリッチjsから戻した
制約をバランスすることこそが設計
みんなの routes.rb
https://gist.github.com/3109082
routes for current_user (ppworks)https://gist.github.com/3116400 routes for users (ppworks)
https://gist.github.com/3127838 基本的なルーティング設定 (shu_0115)
基本的なルーティング設定。
omniauth用のルーティングとroot以外は全て「match ':controller(/:action(/:id))(.:format)'」で受け取る。
RESTは不採用。https://gist.github.com/3182589 URLパラメータを使ったルーティング (kozo002)
https://gist.github.com/3162077 http://proofoflife.me のroutes.rb (takuyan)
https://gist.github.com/3224707 confirmationを使う場合にRESTfulっぽくなるようにしてみた (kozo002)
みんなの質問
確認画面、完了画面、ステップ（ウィザード）型入力フォーム
https://gist.github.com/3159770 (deeeki)
(fukajun)
confirm, finish(complete) アクションを追加すべきか？
アクションは場合によって追加してもよいが、URLに出してはダメ。なぜなら、GETする意味のないリソースだから。
（他サーバからのリダイレクトで、トークン付きGETならギリギリセーフ。その場合名詞形confirmationを使う）
validationを利用する方法 http://beyond.cocolog-nifty.com/akutoku/2011/05/rails-a0d6.html
今気づいたけど、Railsでバリデーションエラーになったときのステータスコードがおかしい？ 200 OK を返してしまっている。400 Bad Request を返すべきでは？
ちゃんと422が返ってました。
ウィザード型
アトミック性がほしいのかどうか？アトミックならトランザクションリソース。いらないなら普通のリソースにPUT連続でいい。
- トランザクションリソースを使う 実際のデータはセッション or DB。DBの場合定期的に削除
データがどこに保存されるかは実装の都合の話で、あまりリソース設計の話じゃない感じも。リソース設計としては同じでは。
複数作れる場合、POST→PUT→PUT→…
1つしか作れない場合、 PUT→PUT→PUT→…
マイページ
https://gist.github.com/3159770 (deeeki)
(ppworks)
もしつくるなら、「自分自身」に紐付くものだけ、URL名前空間を分けるのがよい。（Private Namespace パターン）
RESTfulにする事によってユーザにはどんなメリットがあるのか (shu_0115)
『routes.rbの「match ':controller(/:action(/:id))(.:format)'」はなぜ使わない方が良いのでしょうか？』 http://qa.atmarkit.co.jp/q/2331
Cool URI（URLを変えるべきではない）の観点と、実装依存の観点
Webを支える技術 p.55
メソッド名やセッションIDを含めない
http://example.jp/Login.do?action=showPageもっと問題なのはshowPageというメソッド名がURIに入っていることです。なぜこれが問題かと言うと、たとえ同じStrutsフレームワークを使っていても、システムをリファクタリングしてメソッド名を変更したとたんにURIが変更になってしまうからです。
DRYの観点
GET /people/show/1こんな風に呼ぶのは無駄、 DRY じゃない。 だって、GETってことは、つまりshowしたいんだから
GET /people/1こうできないと駄目だ。
Railsのurl_for, form_forなどの利便性の観点
RESTfulが前提でできてる。
結局、URLの重要度をどれくらい評価するか、かなぁ。
その他ネタ
routes.rbの簡単なチェックポイント
- resources (resource) を使っているか* get ’名詞(形容詞)’ はOKだけど動詞はダメ* post, put, delete はあやしい
- GETできないURLは不自然だから* match は問題外
- あらゆるメソッド通しちゃう