RailsにおけるRESTfulなURL設計勉強会 vol.2 メモ #sendagayarb - 130単位
zusaar.com - zusaar リソースおよび情報 vol.1に続いて参加してきました。そのメモです。 複数レコードを選択して更新するUI 207 Multi-Status を使わないようにがんばりたい 207のレスポンスの中身は設計者任せとされている 項目(トラフィック)が少なければ個別のアクセスもあり Ajaxで複数回リクエストするのはリソース設計の統一感がある 処理を集約したトランザクションリソースを新たにつくる ステータスコード 参考：no title 一部成功時、200を返すのもOK 1の位が0のステータスコードは曖昧さも許容している リソース更新失敗は422 Unprocessable Entity がRailsデフォルト デフォルトに従うのは楽だしその判断もあり しかし表現できるなら表現したほうがいい Uniquenessのバリデーション失敗時は 409 Co
RESTful APIとしてのRailsとクライアントとしてのJavaScript - ppworks.jp
RailsにおけるRESTfulなURL設計勉強会 千駄ヶ谷.rb #12 #sendagayarb にて発表予定の記事です。 この記事は、qiitaのRESTful APIとしてのRailsとクライアントとしてのJavaScriptにも掲載しています。 よくあるAjaxを利用したページの例 Sedndagaya.rbというグループへ投稿出来るサイトがあるとします。 この時、グループのページにアクセスすると、グループの詳細情報と、グループへ投稿された記事が表示されます。 このとき、大きく分けて3つの描写が行われます。 通常のリクエストに対するレスポンスの描写 非同期のリクエストに対するレスポンスの描写 DOM要素のイベントに対するレスポンスの描写 その時の流れは以下のようになります。 エンドユーザーがあるURIをブラウザ経由でアクセスする。 たとえば、 http://example.com
RailsにおけるRESTfulなURL設計勉強会 メモ #sendagayarb - 130単位
zusaar.com - zusaar リソースおよび情報 参加してきました。 以下、粒度にばらつきありますが、気になった点のメモです。ほぼ引用ですが、意図と違う表現になってしまっていたらすみません。 RESTful APIとしてのRailsとクライアントとしてのJavaScript (@ppworks) no title RESTfulの指向で考えると統一されたインターフェースで、URLを見ただけで何するかわかるのが良い JSはassetsのほうに統一しアクションごとに処理が書けるjQuery-Routerなどを使うと良いのでは RailsはだんだんAPI化していくのではないか 通常のHTTPリクエストと非同期HTTPリクエストを同じ統一インターフェースであるRESTfulな設計で管理すると一貫性が出て開発効率の向上につながる リソースモデリングパターンの提案 (@tkawa)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リソースモデリングパターンの提案 #sendagayarb
Railsによるurlの描き方
RESTとRailsスタイル
