私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? t_wada さんの議論のポイント http://www.slideshare.net/t_wada/restful-web-design-review より。 やりたいこと vs. (Rails的な)作りやすさ 確認画面、プレビュー画面、完了画面… リソースの移動、コピー トランザクションの表現 複数レコードを選択して更新する UI 207 Multi-Status の誘惑 URLに機械採番の id が含まれる セキュアじゃ無い 永続的でない（かも） APIのバージョニング 自前でやっていた https://github.com/bp
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く