APIのURL設計をしようと思い、その前に有名サービスのAPIのURL設計がどうなっているのかについて調べました。 一覧を載せた後に、「多数派なURL設計」を書きたいと思います。

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
legacy wild controller route ':controller(/:action(/:id))(.:format)' は使わない派 利用するURLを明示しておきたい named_route使えないとリンクの記述が冗長になるのでは namespaceなど少し複雑なことをやろうとすると何かしらルーティングを書くことになり、統一感がなくなる 確認画面 confirmアクションの追加 各アクションがすっきりする 新規と編集で挙動が変わる場合 (edit_confirmアクション?) パラメータ(mode=confirm)またはモデルの確認用プロパティ(http://bit.ly/mRQ8I5) ifの分岐が見づらいかも 完了画面 finish or completeアクションの追加 パラメータ(finished=1)でshowアクションとか ステップ型入力フォーム 各アクション
今回は直接Railsとは関係ないのですが、先日こういうページを見つけました。 http://redrata.com/restful-uri-design/ これは2009年に書かれたもののようですが、URL設計に関する重要な考え方がいろいろ書かれています。 その中に、このブログのシリーズの(4) スラッシュと「持っている」関係や(5) Railsのリソースパターンの前段階になるような“Choosing a URI schemes for resource hierarchies”という話があったので、かいつまんで紹介したいと思います。 リソースの階層に対して、どういうURLを設計するか? 前提として、設計するWebサイトには、conversation(会話)というリソースが複数あり、それぞれのリソースはユニークなIDで区別されるとします。(IDは数字とは限らない識別子) /conversa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く