RESTURL命名约定/items/{id}vs/items？id={id}

我知道在MVC模式和REST服务中，像

/items/{id}

这样的URI很常见，但是在URI中使用查询参数有什么不好的地方呢

GET/items/{id}

vs

GET/items？id={id}

此外，假设一个实体具有指向某个相关（比如父）实体的“referenceId”字段，我需要创建REST服务来获取父实体的所有项，哪种方式更好：

GET(POST) /items/parent/{parentId} 

或

---

非常感谢能够帮助我解决为REST服务构建URL的主观问题的见解。

当然，REST原则并不关心URL的美学细节。它只是强制要求每个资源都应该是唯一可寻址的

此外，使用查询参数来唯一地解决某些“某种”问题违反了“参数”的语义，不是吗？参数应该是可选的、附加的和参数化的。例如，类似于对项目集合的详细搜索

你写的东西在某些情况下可能有意义。视情况而定

在您的示例中，项目真的是资源吗？如果没有，您可以执行

GET（POST）/parents/{parentId}

如果

parent

是一个布尔值，并且您希望搜索parent等于true的项，那么使用参数是有意义的。但是，因为您明确地说您想要一个具有特定id的父级，所以我假设父级本身就是一个资源，我将使用您的选项1唯一地寻址该资源

---

我希望我能说清楚。

我会使用以下方案

/items/id

这将唯一地寻址id为

id

的项目资源。我们不使用参数作为唯一寻址此资源的参数（与其他选项一样）。正如 米格尔拜恩建议

/parent/id/items

这里的

id

是一个id，用于唯一地寻址父资源，并从这些资源中收集/检索它引用的项。从您在问题中所说的内容来看，家长似乎引用了多个项目，如容器或集合

我使用的惯例是缩小从左到右的范围。因此，在这种情况下，项目可能处于活动状态或非活动状态。因此，有些项目的属性或属性是

活动的

或

非活动的

。缩小范围，我得到以下方案：

/items/active
/parent/id/active

---

关于你的第一个问题：

/items/{id}

应检索具有指定id的单个资源，或者

404

如果它不存在

/items/？id={id}

应该检索数组（即使数组中只有一个），因为您正在查询集合

关于第二个问题：

我同意@miguelcbain的评估——如果项目是特定的资源/实体，只需使用适当的资源路径检索即可

---

为了让使用者更容易使用，请使用

rel=“parent”

创建一个uri，并/或在子资源中包含uri。有关链接头的示例，请参阅GitHub。

在我看来，似乎没有规则可遵循

items/{id}

-此约定适用于按给定id获取项目。如果用户不提供id，则返回404状态代码

---

items/id={id}&name={name}

-这种约定适用于根据给定条件搜索多个项目。如果没有找到任何项目，则不是404情况，您只需说“我成功地找到了与您的搜索条件不匹配的项目”

我认为项目是资源。它存储在单独的集合（表）中。而家长其实是太资源了。你认为什么更合适：/items/parent/{parentId}或/parents/{parentId}/items？肯定是

/parents/{parentId}/items

。这种URL经常出现。我认为项是资源，它有唯一的ID，可以在没有父参数的情况下查询。它存储在单独的集合（表）中。而家长其实是太资源了。您认为什么更合适：/items/parent/{parentId}或/parents/{parentId}/items？我认为item是资源，它有其唯一的id，可以在没有父pareamter的情况下查询。它存储在单独的集合（表）中。而家长其实是太资源了。所以我需要按家长“筛选”项目。在这种情况下，您认为什么更合适：/items/parent/{parentId}或/parents/{parentId}/items？

/parents/{parentId}/items

，因为这样可以从左到右缩小范围。Parentscollection=>single parent=>attributecollection on Parents从问题中引出：可以找到关于复杂REST URL的好建议

/items/active
/parent/id/active