REST URL 命名约定 /users/{id}/cars/{carId} 与 /cars/{carId}?答案

【问题标题】：REST URL naming convention /users/{id}/cars/{carId} vs /cars/{carId}?REST URL 命名约定 /users/{id}/cars/{carId} 与 /cars/{carId}?
【发布时间】：2019-01-21 11:02:48
【问题描述】：

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

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

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

谁给我们解释一下
为什么第二个是推荐的命名
但是，我只需要 carId 来取车
也不需要userId

【问题讨论】：

标签： rest api web-services uri naming-conventions

【解决方案1】：

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

GET /users/user001/cars/car001 回复：车主姓名、车牌号、购买日期、第一任车主这里的响应是 - 特定于用户的汽车详细信息

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

【讨论】：

【解决方案2】：

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

/a4e199c3-ea64-4249-96aa-abb71d860a55

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

您链接的指南应该被理解为样式指南；遵守本地拼写约定的人类可读标识符是好的，原因与遵守本地拼写约定的人类可读变量名完全相同。

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

当我阅读 REST 资源标识符 (URI) 命名的最佳实践时我发现最好将父信息放在 URI 中

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

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

在 HTTP 中，您甚至可以向客户端发送这些资源的表示形式与另一种等价的信息（请参阅RFC 7231）。

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

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

【讨论】：