以RESTful方式建模更复杂的实体关系（框和节点）

这里有一个例子来说明我的问题。我有一个包含“盒子”的模型，它们有一个REST端点：

/box

，

/boxes/{boxId}

此模型还包含“节点”：

/nodes

，

/nodes/{nodeId}

节点可以位于框的边界上，这是一种多对多类型的关系。让一个节点位于多个边界上是一种表示这些边界（部分）重叠的方法，但节点还有其他用途

我正试图确定如何以一种不出所料、宁静的方式对此进行建模。我可以找到几种方法来做到这一点。但我不确定应该使用哪种：

将

/borders

建模为具有自己端点的成熟实体类型。框参照四个边框（顶部、底部、左侧、右侧）。使边框引用节点列表。让节点引用边界列表

Model

/boxNodeRelationships

具有自己的端点，并使每个此类关系指向一个框、一个节点，并包含一个“border”字段（一个具有四个选项的枚举）

两者都是相似的，就其用途而言相当“沉重”。另一种选择是更特别一点：

为框提供

{border，node}

对象的列表。为节点提供

{box，border}

对象的列表。这些对象将从

GET

调用返回，并从

POST

/

PUT

调用预期返回，但不会是具有端点的完全成熟类型

---

我想知道RESTifarian如何解决这个问题，以及这些方法的优缺点。我还想知道是否还有其他根本不同的方法。

我将创建3个实体：

• 盒子
• 边界
• 节点

以及这些关系：

• 一个盒子可以有n个边框
• 一个边框可以有n个节点

因此，您可以解决这些问题：

要获取第一个节点：

/box/1/borders/1/nodes/1

你可以有一些逻辑：

if /boxes/1/borders contain /nodes/1 and /boxes/2/borders contain /borders/1 then they intersect

---

等等。

这确实是我在问题中考虑并列出的可能性之一。但与其他方法相比，这种方法的优势是什么？从某种意义上说，这是“标准”吗？选项2如何对抗HATEOAS？据我所知，这实际上是一种多对多的关系。选项1的缺点是“边界”是一个相对无用的实体；一个额外的重定向只是为了解决这个问题。它们各有利弊。我希望得到专家的比较分析。在我看来，关系不应该作为单独的实体（/boxNodeRelationship）暴露为web服务端点。这些本身不是实体。这些不是业务对象。当然，可能不是它们自身的终点。但是，这样做的想法是，例如，

/nodes/{id}/boxNodeRelationships

和

/boxes/{id}/boxNodeRelationships

。（我想，为了完整性起见，将它们作为端点提供是可选的。）我个人不喜欢这种设计。为什么

/nodes/{id}/box

-将返回

id

节点的所有框？要找到对API建模的最佳方法，您需要了解最有可能使用它的用例。@astr：我们需要各种方法来处理此数据，真的，例如，获取边界上的所有节点，将所有框连接到一个节点，让所有的盒子连接到另一个盒子，等等。所以我想知道最优雅的RESTful API，它提供了对数据的完全访问。