REST URL命名约定/ users / {id} / cars / {carId}与/ cars / {carId}？

Question

我有一个简单的模型
每次使用可以有多辆车

现在，当我决定为Cars服务命名相关的REST URL命名时
最初，我建议如下所示
GET /cars/{carId}

但是当我读到有关best practices in REST Resource Identifier (URI) Naming
我发现最好将父信息放在URI中，如下所示
GET /users/{userId}/cars/{carId}

任何人向我们解释
为什么第二个是推荐的命名方式
但是，我只需要carId来取车
无需userId

Answer 1

IMO，这更多地取决于上下文。考虑以下示例：

获取/ users / user001 / cars / car001 响应： 车主名称，汽车许可证编号，购买日期，第一所有者 这里的响应是-特定于用户的汽车详细信息

获取/ cars / car001 响应： 汽车型号，制造商，排量，汽车类型 这里的响应是-特定于汽车的汽车详细信息

Answer 2

REST不在乎标识符使用什么拼写。

/a4e199c3-ea64-4249-96aa-abb71d860a55

是完全令人满意的REST标识符。

应该将诸如您所链接之类的指南理解为一种样式指南；遵循本地拼写约定的人类可读标识符之所以具有优良性，是因为与遵循本地拼写约定的人类可读变量名称完全相同。

某些URI准则倡导者convention over configuration-概括地说，如果选择标识符拼写可以使框架推断出事物应该存放的位置，则可以简化实现。

  

当我阅读有关REST资源标识符（URI）命名的最佳做法时   我发现最好将父信息放入URI

也许；问题的一部分可能是资源与实体混淆。数据库中的单个行贡献许多不同资源的表示是完全正常的，每个资源都有其自己的标识符

/users/:userId/cars/:carId
/cars/:carId

在HTTP中，您甚至可能向客户端发送以下信息：这些资源之一的表示等同于另一资源（请参见RFC 7231）。

好消息：超媒体客户端可以自动处理这种事情，因为它们已经内置了对链接语义的了解；具有网络意识的超媒体客户端（例如浏览器）也将能够对元数据执行正确的操作。

坏消息：您可能没有使用超媒体类型作为表示形式，所以您不会看到这些好处。