Hatena::ブログ(Diary)

130単位

2012-07-24

RailsにおけるRESTfulなURL設計勉強会 メモ #sendagayarb

参加してきました。

以下、粒度にばらつきありますが、気になった点のメモです。ほぼ引用ですが、意図と違う表現になってしまっていたらすみません。

RESTful APIとしてのRailsクライアントとしてのJavaScript (@ppworks)

  • RESTful指向で考えると統一されたインターフェースで、URLを見ただけで何するかわかるのが良い
  • JSはassetsのほうに統一しアクションごとに処理が書けるjQuery-Routerなどを使うと良いのでは
  • RailsはだんだんAPI化していくのではないか
  • 通常のHTTPリクエストと非同期HTTPリクエストを同じ統一インターフェースであるRESTfulな設計で管理すると一貫性が出て開発効率の向上につながる

リソースモデリングパターンの提案 (@tkawa)

RESTful Webアプリの設計レビューの話 (@t_wada)

  • 結論:「REST麻疹である」
    • 良いものであるからこそ広まっている
    • ただし近づきすぎるとデメリットもある
  • URL動詞は含めない
    • なるべく名詞に近づける努力
    • URLのかっこ良さに引かれるのは疑問
  • コピー先はコピー元と従属関係がないため階層構造は不当
  • URL設計のほとんどの時間は「名前を探す」ことに費やされる
  • 第三のリソースを探す
  • リソースの粒度/視点(つまりはURL)とデータベースの粒度/視点の違いを解釈してしかるべく結びつけるのがControllerの仕事
    • URLの言葉をDBの言葉に橋渡しする
  • HTTPメソッドの選択
    • URLが新たに作成される場合はPOST、URLがわかっている場合はPUT
    • どうにもならない場合はPOST
  • 接続性ある表現のために
    • サービスはクライアントURLを組み立てることを強制してはならないし、期待してはならない
    • クライアントが次に取りうる状態をすべてリンクまたはフォームの形で表現に含めるべき
    • クライアントURLを知り過ぎないようにする
  • RESTfulサーバとリッチJSという設計にしすぎるとUXが低下する可能性もある
  • 矛盾し合ういろんな制約のバランスを取ることこそが設計

1周めのリソース設計 (@moro)

  • routes.rbにいきなりmatchとか書き始めるとドツボにはまる。書くのはリソース設計があらかた決まってから
  • 例「イベント登録」
    • events <-> registrations <-> users
    • /events/42/add_users
      • イベントにユーザーを追加する? よりも
    • /events/42/registrations
      • イベントの参加登録情報を作る
  • ユーザーから見てわかりやすい形で流通させるのがリソース
  • 単純なCRUDはRailsAdminでできる
  • memberはそのリソースの一部だけを扱うときに使える
    • 「メンバ変数」のメンバ
    • /users/42/token

その他

  • パターン化したアクションはEngineに割り当てる
  • routes.rbにあまり更新が発生しないようにする
  • routes.rbの9割くらいはresource(s)でまかなっている
  • リソースの部分的な更新はあまりやらない設計にする
  • まずはベタなところで動くことを考える

感想

@さんのリソースモデリングはどれもしっくりくる命名で感心しました。@さんの発表は時間の割に情報が凝縮されまくっていて圧倒された上にとてもためになりました。メモれなかったところを復習したいのでスライド公開期待です。

勉強会後に自然と開発意欲の湧いてくる、素晴らしい内容だったと思います。ありがとうございました!

あわせて

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/deeeki/20120724/rails_restful_modeling