1

我有一个 URI 结构，它对特定数据集是分层的：

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

如果 url 以不同的 ID 拆分，您可以获得该特定资源，例如：

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

这将获得与需求 #2 相关联的风险 #2

问题是这样的：现在需要的功能是能够在同一个 HTTP 请求中更新（PUT）和删除（DELETE）一组需求。（当您向/BlackboardURL 发送 HTTP GET 时，整个“需求”集都是 GET 的——这是默认功能，因为有些东西是写在黑板上的，形象地）

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

/Blackboard/Requirements : HTTP PUT/DELETE

（注意复数）

或者实际上使现有的 URL 结构复数

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

后者似乎打破了语义一致性，因为层次结构中的其他项目是单一的。我也应该让它们复数吗？

拥有一个项目 id 是否有助于消除奇异性（从人类的角度来看 :)Blackboard/Requirements/1或者是否最好仅出于操作原因公开不同的资源（即集合）（因为没有 id 不允许 GET - 无论它是单数还是复数）？

只是想知道社区对通常选择哪种方法（或者是正确的方法）以实现清晰清洁设计的意见。

4

1 回答 1

1

后者似乎打破了语义一致性，因为层次结构中的其他项目是单一的。我也应该让它们复数吗？

你应该希望你的网址很酷。因此，如果您确实更改它们以使其匹配，请确保您的旧单数 url 返回带有新位置的重定向。确定其中的代价可能有助于做出改变/不改变的决定。如果您的 API 尚未使用，那么无论哪种方式都没有障碍。IMO，我会追求一致性。

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

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

于 2011-06-29T20:15:29.150 回答