嵌套资源的唯一ids

Question

我有几个嵌套资源，如Merchant、Hotel、Room。一个商人可以有许多旅馆，同样，一家旅馆也可以有许多房间。现在，为了管理这些资源，我做了如下工作：

创建

POST api/v1/merchants/11/hotels

新建了一家酒店。

更新

放置api/v1/merchants/11/hotels/42

更新给定的酒店。

相同的阅读和删除。

适用于客房：

创建

POST api/v1/merchants/11/hotels/42/rooms

创造了一个新房间。

更新

放置api/v1/merchants/11/hotels/42/rooms/42

更新给定的房间等。

将来会有更多的嵌套资源，如房间设施等，按照这个方案，就会变得多姿多彩。

我正处于开发的早期阶段，我可能会向开发人员公开这些API，因此我不能很快地更改API方案。

从第一天起，我就对这一做法表示怀疑。我是否可以假设每个实体都有唯一的ID (因为我现在使用的是关系数据库，并且有自己的表)？如果是，那么我可以将这些URL用于API而不是上面的吗？

POST api/v1/rooms

放置api/v1/rooms/42

等等，以获得更多嵌套资源。

是否有任何违反语义学或标准，我可能会错过？我在视图中使用了类似的方法。在浏览器中的URL中，看起来也很难看。

Answer 1

按照这个计划就会变得毛茸茸的

你能解释一下为什么你认为嵌套设计不好吗？

我可以假设每个实体都有唯一的ID吗？如果是，那么我可以将这些URL用于API而不是上面的吗？ POST api/v1/rooms PUT api/v1/rooms/42

通常，每种类型的实体都有自己的id空间，每个实例都有来自该空间的id。每个房间都有一个与其他房间不同的身份证。它不必是这样的，但通常是这样的，是的，这会给你灵活性，并允许你采用你所建议的平面结构。

一开始，我想也许平铺的结构会更好。它允许您管理酒店或房间，而不必了解父实体，但在考虑了问题后，您需要了解商人和酒店才能更换房间。我认为一间酒店只属于一间商户，而一间房间只属于某一间酒店，对吗？如果这些是一对一的关系，那么嵌套结构就很有意义了。

您所做的选择最终将由您的用例决定。开发者将如何访问您的API？他们只会看一个商人吗？--如果是这样的话，你可能不想向他们展示merchant层(从身份验证中查找商人)。他们是否会在API中的每一个房间或酒店进行迭代，而不管商人是谁？-如果是这样的话，平面结构就很有意义了。回答这些问题将帮助您决定如何构造您的API，并且您可能会决定需要一个平面结构和一个嵌套结构来满足您的所有用例。