用于嵌套资源的 RESTful api答案

【问题标题】：RESTful api for nested resource用于嵌套资源的 RESTful api
【发布时间】：2017-12-17 16:48:12
【问题描述】：

我有两个实体Hotel、Merchant，每个商家可以有很多酒店。现在我有一个这样的 api 端点：

/api/v1/merchants/{id}/hotels/{id}

但我在想这种语义有什么问题：

/api/v1/hotels/{id}

后面的也很短。

【问题讨论】：

【解决方案1】：

根据我的经验，后者更可取，因为它在以后为您提供了更大的灵活性。六个月后，有人会说：“嘿，我希望能够查看阿格拉巴的所有酒店”。第一个 URL 方案让这很痛苦——您需要添加一个新端点。第二个 URL 方案通过查询参数支持它：GET /hotels?location=Agraba。

您可能希望将 /merchants/{id}/hotels 保留为集合端点，以便您可以通过 POST/DELETE 添加/删除特定商家的酒店。

【讨论】：

我同意，因为理想情况下，我们应该为实体的每个实例生成唯一的 Id。我只是对 REST 语义感到困惑。
REST 对 URL 设计没什么好说的。在 REST 中，URL 是不透明的——它们不包含语义值。 URL 中的语义内容只是为开发人员提供 API 设计便利。
不。我是说GET /329ffkdq-dkfh/1234jfkdlf 在 REST 中与GET /hotels/12 没有什么不同。 @alexandrumarculescu 说你不应该在 /hotels/12 和 /merchants/5/hotels/12 上支持相同的操作——酒店应该只住在一个地方。
这是有道理的，但现在假设我在酒店内有很多房间，然后找到一个带有 AC /rooms?facility=ac 的房间将返回每家酒店的所有房间，但 URL 像 /hotels/id/rooms?facility=ac 我敢肯定搜索将被限制在该酒店内。你有什么建议？
@CodeYogi GET /rooms?hotel=XXX&facility=YYY

【解决方案2】：

在REST 中，每个URL 都应该唯一标识一个资源。

因此，如果酒店的id 是全球唯一的，那么使用较短的链接当然没有问题。但是，如果酒店 id 1 对商家 1 和商家 2 的含义不同，那么您应该坚持使用第一个 URL（基本上是唯一的复合键）。

【讨论】：