区分集合和单例资源的首选 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 时，整个“需求”集都是 GET 的——这是默认功能，因为有些东西是写在黑板上的，形象地）

所以我应该像这样创建一个只支持 PUT/DELETE 的新集合资源 URL：

/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 尚未使用，那么无论哪种方式都没有障碍。 IMO，我会追求一致性。

是否具有项目 ID 有助于消除奇点（从人类的角度 :) 像 Blackboard/Requirements/1 或者纯粹出于操作原因公开不同的资源（即集合）更好（因为 GET 不允许没有id - 无论是单数还是复数）？

对我来说，将 url 集合设为复数更有意义，即使是 id。不过，这可能是文件系统的偏见。从这个意义上说，只有单个资源在 url 中比集合资源更深才有意义。它还提供了一种返回集合资源的简单方法，即 url 面包屑。