コレクションとシングルトンリソースを区別するための好ましいRestful URIの設計は何ですか？

Question

私は特定のデータ・セットの階層であるURI構造を有する：

/Blackboard/Requirement/{reqID}/Risk/{riskId}/MitigationPlan/{planId} 

URLは、様々なIDがで分割されている場合は、その特定のリソースなどを取得することができます。

GET: /Blackboard/Requirement/2/Risk/2 

これはリスク＃を取得2が要求＃2に関連付けられている

問題はこれです：所望の機能が、同じHTTP要求内の要件のセットを更新（PUT）および削除（DELETE）できるようになりました。 （/Blackboard URLにHTTP GETを送信すると、設定の全体が取得できます。比喩的に何かが黒板に書き込まれているため、デフォルトの機能です）

新しいコレクションリソースのURLを作成する必要がありますのみサポートPUT/DELETEのように：

/Blackboard/Requirements : HTTP PUT/DELETE 

（複数の点に注意してください）

または実際

/Blackboard/Requirements/{reqID}/Risk/{riskId}/MitigationPlan/{planId} 

既存のURL構造を複数作ります

後者は、階層内の他の項目が特異であるため、意味の一貫性を壊すようです。私もそれらを複数にする必要がありますか？

アイテムIDを持つと、Blackboard/Requirements/1のように特異点が明確になりますか（つまり、GETはidなしで許可されていないため、別のリソース（つまりコレクション）を公開することが望ましいですか？それは単数形か複数形か）？

明快でクリーンなデザインのために、アプローチが一般的に選択されているコミュニティの意見を知りたかっただけです（またはそれを行う正しい方法です）。

Answer 1

後者は、階層内の他の項目が特異であるため、意味の一貫性を失うようです。私もそれらを複数にする必要がありますか？

url's to be coolが必要です。したがって、一致させるためにそれらを変更する場合は、古い特異URLが新しい場所でリダイレクトを返すようにしてください。その高価なものを判断することは、変化の有無を判断するのに役立ちます。あなたのAPIがまだ使用されていない場合、どちらか一方の方法で障壁がありません。 IMO、私は一貫性のために行きます。

がGETであるため（運用上の理由から、純粋に人間の視点から:)黒板等/条件/ 1またはそれが異なるリソースを公開することが好ましい（すなわち、収集）（アイテムIDヘルプ明確特異点を有していidなしでは許されない - 単数形か複数形かにかかわらず）？

私にとっては、idでも複数のURLコレクションを持つ方が意味があります。しかし、それはファイルシステムからの偏見かもしれません。その意味では、コレクションリソースよりも単一のリソースがURLの方が深いことが理にかなっています。また、コレクションのリソース、つまりURLブレッドクラムに簡単に戻ることができます。