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

Question

我有一个简单的模型
每个 Use 可以拥有多辆汽车

现在，当我决定为 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 回复： car-model-no，制造商，排量，车型这里的响应是 - 汽车详细信息，特定于汽车

Answer 2

REST 不关心您使用什么拼写作为标识符。

/a4e199c3-ea64-4249-96aa-abb71d860a55

是一个非常令人满意的 REST 标识符。

诸如您链接的指南之类的指南应该被理解为一种风格指南；出于与遵守本地拼写约定的人类可读变量名称完全相同的原因，遵守本地拼写约定的人类可读标识符是好的。

一些 URI 指南提倡 convention over configuration -- 广义地说，如果您选择标识符拼写，允许您的框架推断事物应该存在的位置，您可以简化您的实现。

when I read about best practices in REST Resource Identifier (URI) Naming I found that its better to put parent information in the URI

也许；部分问题可能是混淆了资源和实体。数据库中的一行代表许多种不同的资源，这是完全正常的事情，每个资源都有自己的标识符

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

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

好消息：超媒体客户端可以自动处理这类事情，因为它们内置了对链接语义的感知；网络感知超媒体客户端（例如：浏览器）也将能够对元数据做正确的事情。

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

REST URL naming convention /users/{id}/cars/{carId} vs /cars/{carId}?