2

URLデザインに関する初心者のPlayFrameworkの質問：Playフレームワークにとってより慣用的なものを探していますが、これはある意味でより一般的なURLデザインの質問になる可能性があると思います。

これらは私の実際のエンティティではありませんが、次のようなもので編集できるコレクションがあるとします。

GET /collections/:id controllers.Collections.edit(id: Long)
POST /collections/:id controllers.Collections.update(id: Long)
POST /collections/:id/delete controllers.Collections.delete(id: Long)

そして今、各コレクションはアイテムを持つことができます。アイテムは独自のIDでデータベースにありますが、外部キー制約のある親コレクションのIDも持っています。

だから私はこれらを持っているのを見ることができました：

GET /collections/:collection/items controllers.Items.list(collection: Long)
GET /collections/:collection/items/new controllers.Items.create(collection: Long)
POST /collections/:collection/items controllers.Items.save(collection: Long)

しかし、既存の個々のアイテムを編集または削除して、アイテムIDだけでアイテムのコレクションIDを取得できるようにするには、次のようにします。

GET /items/:id controllers.Items.edit(id: Long)
POST /items/:id controllers.Items.update(id: Long)
POST /items/:id/delete controllers.Items.delete(id: Long)

または私は代わりにこのようなことをしたいですか？：

GET /collections/:collection/items/:id controllers.Items.edit(collection:Long, id: Long)
POST /collections/:collection/items/:id controllers.Items.update(collection:Long, id: Long)
POST /collections/:collection/items/:id/delete controllers.Items.delete(collection:Long, id: Long)

頭に浮かぶ考えの1つは、複合キーを使用した場合（良くも悪くも）はど​​うなるかということです。2番目のセットを使用して、現在のスキーマのアイテムIDのみが必要であるという事実からインターフェイスを分離する必要がありますか？それとも、その2番目のセットは完全に偽物で無駄ですか？理論的には、既存のアイテムに対して間違ったコレクションIDを持つURLを許可します（それを確認することはできますが、それでも）。

（上記ではより多くのRESTful PUT / DELETEを使用しますが、現時点では通常のHTMLフォームを使用していることに注意してください）

（これがFAQの場合は申し訳ありませんが、このようなものは実際には見つかりませんでした）

4

1 に答える 1

2

Play 2.0には、組み込みの自動コントローラー/アクションルートがないため（Play 1.xで可能だったように）、事実上、ルートのパターンは定義されていません。

つまり、独自のパターンを実行でき、ルートが有効であることを確認する必要があるのはあなただけです。私の考えと実践のいくつかがあります：

/collections/つまり、または/items/：のような冗長なプレフィックスは使用しないでください。

http://domain.tld/presentation/collections/1/items/1

ユーザーがアドレスバーの最後のセグメントを削除すると、どこも指しません。

http://domain.tld/presentation/collections/1/items (404 as no such route)

代わりに、ユーザーが変更する場合でも、適切なものを提供する準備ができているURLを作成してみてください。

http://domain.tld/presentation/1/1 (display single item 1 in collection 1)
http://domain.tld/presentation/1   (list of items in collection 1)
http://domain.tld/presentation     (list of collections)
http://domain.tld/                 (main page)

もちろん、そのような場合は、データベース内のレコードを識別するための文字列キーを作成して、リンクをユーザーフレンドリーにする方がよいでしょう。

http://domain.tld/t-shirts/autumn-2012/play-geeks-shirt-red-xl
http://domain.tld/tasks/project-1/prepare-correct-routes

もちろん、文字列識別子が信頼できない場合は、スタックオーバーフローのようにリンクを作成できます。ここで、最後から2番目のセグメントは数値IDであり、最後の1つは検索エンジンと人間の文字列であり、レコードを検索する意味はありません（開いてくださいリンクhttp://stackoverflow.com/questions/12719857すると、現在の質問も表示されます）

私は個人的にフロントエンドに追加の数値IDのない文字列識別子を好みますが、選択したパスで一意であるかどうかを確認し、追加のデータをDBに保存する必要があります。

バックエンドの場合は、最初に安定したプレフィックスを使用し、コントローラーを分離することをお勧めします（多くのアクションに注釈を付けるよりも、コントローラー全体に1つの承認ルールを設定する方が簡単です）。もちろん、レコードの編集に文字列識別子を使用することは冗長な作業です。

http://domain.tld/admin/1         (list of items from first collection)
http://domain.tld/admin/1/edit    (edit form for first collection)
http://domain.tld/admin/1/1       (edit form for item 1 in first collection \), 
       it hasn't got subitems so there's no need to display its preview first

http://domain.tld/admin/1/1/edit  (alternative, same action as above)
       in this case you should prepare redirect from admin/1/1 to admin/1/1/edit,
       otherwise you'll get same form available on two URL's (for each record) 
       which can be confusing

delete、、アクションは通常save、最後のセグメントとして実行されます（ただし、よりRESTfulにするには、最後にサフィックスの updateないDELETEルートとして宣言する必要があります）。/delete

 http://domain.tld/admin/1/1/delete

とにかく、レコードの削除にGETを使用する場合は、計算されたハッシュをURLに追加し、DBからオブジェクトを削除する前に確認することをお勧めします。それにはより良いものがあるので、それは承認メカニズムではありません、それはあなたが手動でURLを書くことによってあなたが誤ってレコードを削除しないことを確実にすることを可能にするだけです、それでそれはレコードIDの例のMD5ハッシュであるかもしれません：

 http://domain.tld/admin/1/1/delete?confirm=a76fe878988ced8...

最後に、コレクションとアイテムの両方が厳密に相関していない場合は、別々の「url-spaces」でそれらを編集するためのリンクを作成できます。

 http://domain.tld/admin/collections/1/edit
 http://domain.tld/admin/items/1/edit
 http://domain.tld/admin/contacts/1/edit
 http://domain.tld/admin/offices/1/edit...

このような場合、正しいナビゲーションリンクを準備すれば十分です。おそらく、クリーンで快適なナビゲーションがあれば、管理者がURLを操作することをあまり気にする必要はありません。

于 2012-10-04T10:06:54.133 に答える