我有一个URI结构，它是特定数据集的分层结构：
/Blackboard/Requirement/{reqID}/Risk/{riskId}/MitigationPlan/{planId}
如果网址以各种ID分割，您可以获得该特定资源，例如：
GET: /Blackboard/Requirement/2/Risk/2
这会导致与要求＃2相关的风险＃2
问题是：现在所需的功能是能够在同一HTTP请求中更新（PUT）和删除（删除）一组需求。 （当你将HTTP GET发送到/Blackboard URL时，整个'set'要求都是GET-able - 这是默认功能，因为在黑板上写了一些东西，比喻）
因此，我应该创建一个仅支持PUT / DELETE的新集合资源URL：
/Blackboard/Requirements : HTTP PUT/DELETE
（注意复数）
或实际使现有的URL结构复数
/Blackboard/Requirements/{reqID}/Risk/{riskId}/MitigationPlan/{planId}
后者似乎打破了语义一致性，因为层次结构中的其他项是单数的。我也应该让它们复数吗？
有一个项目ID是否有助于消除奇点（从人的角度来看:)，如Blackboard/Requirements/1，或者仅仅出于操作原因而更好地暴露不同的资源（即集合）（因为没有GET是不允许的id - 无论是单数还是复数）？
只是想知道社区的意见，通常选择哪种方法（或者是正确的方法），以便清晰设计。
答案 0 :(得分：1)
后者似乎打破了语义一致性，因为层次结构中的其他项是单数的。我也应该复数吗？
您应该想要url's to be cool。因此，如果您确实更改了它们以使其匹配，请确保旧的单一网址返回带有新位置的重定向。确定其中的昂贵可能有助于做出改变/不改变的决定。如果您的API尚未使用，那么就没有任何障碍。 IMO，我会保持一致性。
有一个项目ID是否有助于消除奇点（从人类的角度来看:)，如Blackboard / Requirements / 1，或者最好是出于操作原因而公开不同的资源（即集合）（因为没有GET是不允许的） id - 无论是单数还是复数）？
对我来说，使用id甚至将url集合复数更有意义。但这可能是文件系统的偏见。从这个意义上说，只有单个资源在URL中比集合资源更深才有意义。它还提供了一种简单的方法来回收集合资源，即url breadcrumb。