什麼是Restful URI設計來區分集合和單例資源？

Question

我有一個URI結構是分層的特定數據集：

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

如果URL是在各種ID拆你可以得到特定的資源如：

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

這得到風險＃ 2與需求＃2相關聯

問題是：現在需要的功能是能夠在同一個HTTP請求中更新（PUT）和刪除（DELETE）一組需求。 （當您將HTTP GET發送到/Blackboard URL時，整個'設置'需求是GET可用的 - 這是默認功能，因爲東西寫在黑板上，比喻）

因此，我應該創建一個新的集合資源URL僅支持PUT/DELETE這樣的：

/Blackboard/Requirements : HTTP PUT/DELETE 

（注意是複數）

或實際上使現有的URL結構多

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

後者似乎打破語義統一，因爲層次結構中的其他項目是單數。我應該讓他們複數呢？

是否具有項目ID有助於區分奇點（從人的角度來看:)等Blackboard/Requirements/1或者是優選以暴露不同的資源（即，集合）純粹是爲了操作上的原因（由於GET也不是沒有ID允許 - 不論它是單數還是複數）？

只是想知道社區的意見，哪些方法通常選擇（或是正確的方式），以清晰度清潔設計。

Answer 1

後者似乎打破語義統一，因爲層次結構中的其他項是單數。我應該讓他們複數呢？

你應該想要你的url's to be cool。所以，如果你改變它們以使其匹配，請確保你的舊奇異URL返回新位置的重定向。確定昂貴的這可能有助於做出改變/不變的決定。如果您的API尚未使用，那麼就沒有障礙。國際海事組織，我會去爭取一致。

是否具有項目ID有助於區分奇點（從人的角度來看:)等黑板/需求/ 1或者是優選以暴露不同的資源（即，集合）純粹是爲了操作上的原因（由於GET是不帶身份證不允許 - 不管它是單數還是複數）？

對我來說，使用id收集url複數更有意義。儘管如此，這可能是文件系統的一種偏見。從這個意義上說，唯一有意義的是單個資源在URL中比在資源集合中更深。它還提供了一個簡單的方法回到收集資源，一個URL路徑。