1

特定のデータセットに対して階層的なURI構造があります。

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

URLがさまざまなIDで分割されている場合は、その特定のリソースを取得できます。例：

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

これにより、要件＃2に関連付けられたリスク＃2が取得されます

問題はこれです。必要な機能は、同じHTTPリクエスト内の一連の要件を更新（PUT）および削除（DELETE）できるようにすることです。（URLに対してHTTP GETを実行すると、要件の「セット」全体がGET可能になり/Blackboardます。これは、比喩的に何かが黒板に書き込まれるため、デフォルトの機能です）

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

/Blackboard/Requirements : HTTP PUT/DELETE

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

または実際に既存のURL構造を複数形にします

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

後者は、階層内の他の項目が特異であるため、意味の統一性を損なうようです。私も複数形にすべきですか？

アイテムIDを持つことは、（人間の観点から:)のように単数形を明確にするのに役立ちますか、Blackboard/Requirements/1または純粋に運用上の理由で別のリソース（つまりコレクション）を公開することが望ましいですか（単数形であるかどうかに関係なく、GETはIDなしでは許可されないため）複数）？

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

4

1 に答える 1

1

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

あなたはあなたのURLがかっこいいことを望むべきです。したがって、一致するように変更する場合は、古い単一のURLが新しい場所でリダイレクトを返すことを確認してください。その費用を決定することは、変更/変更なしの決定を下すのに役立つかもしれません。APIがまだ使用されていない場合は、いずれにせよ障壁はありません。IMO、一貫性を保つために行きます。

アイテムIDを持つことは、Blackboard / Requirements / 1のように（人間の観点から:)特異性を明確にするのに役立ちますか、または純粋に運用上の理由で別のリソース（つまりコレクション）を公開することが望ましいですか（IDなしではGETは許可されないため-関係なく）単数形または複数形）？

私にとっては、IDを使用してもurlコレクションを複数形にする方が理にかなっています。ただし、これはファイルシステムからのバイアスである可能性があります。その意味で、単一のリソースがコレクションリソースよりもURLの奥深くにあることは意味があります。また、コレクションリソースであるURLブレッドクラムに簡単に戻ることができます。

于 2011-06-29T20:15:29.150 に答える