java - 针对来自不同领域但具有共同关系的实体的 REST API 设计

Question

在一般情况下，当一个实体与另一个实体有关系时，我以这种方式嵌套 REST 资源:

POST /user/{userId}/accounts

对于来自同一域的实体来说这是可以的。但当涉及到来自不同领域的实体时，这就没有意义了。例如，我有公交线路 (@Entity Line) 和运营商 (@Entity Operator)。每行都有一个运算符:

@ManyToOne
@JoinColumn(name = "operator_id")
private Operator operator;

因此，如果我需要创建新的公交线路，我必须通过运营商。

如果我需要使用新运算符创建行，那么没有问题，但如果我只想引用运算符，我需要以某种方式传递operator_id。如何处理这个问题的一些想法:

<强>1。在运算符中嵌套行

POST/operators/{operatorId}/lines {name: "15B", type: "BUS"}

从技术角度来看这是可以的，但我想将运算符和行分开，因为行并不真正“属于”(嵌套)运算符。

<强>2。直接传递operatorId

POST/lines {名称:“15B”，类型:“BUS”，运算符(operator):12}

这件事有一些问题。有一种情况，当我想使用新的 Operator 创建新的 Line 时，查询将如下所示:

POST/lines {名称:“15B”，类型:“BUS”，运算符(operator):{名称:“SuperBUS”}}

我需要处理这两种情况。这将带来额外的实体(因为原始实体有 Operator 运算符，而不是 int 运算符)和“神奇”逻辑，这将决定我是否要使用 new 运算符或创建行旧的。

是否有处理此类情况的最佳实践？

Answer 1

这里有一些想法，可能会也可能不会帮助您决定使用什么:

传递 ID

传递Id将客户端与对象的某些实现细节耦合起来。这通常是应该避免的事情。考虑以下代码:

public Line createLine(String name, LineType lineType, int operatorId);

调用者必须知道operatorId，它通常不是模型的一部分。 id通常只是持久化的实现细节，换句话说，Operator实际上没有id，它有一个< em>最多是名字，但这实际上是可以改变的。

在“正常”OO 代码中，此方法可能如下所示:

public Line createLine(String name, LineType lineType, Operator operator);

在引用的帮助下传递实际的操作符。 RESTful HTTP 中的对象引用相当于什么？当然是URI。这样我们就可以:

POST /lines
{"name": "15B", "type": "BUS", "operator": "http://something/124"}

然而，这种方法还有另一个问题，在 Java 和 HTTP API 中都存在:我们无法确定我们得到的是哪种对象。在Java中，如果Operator是一个接口(interface)，我们不知道我们得到了什么实现。例如，该实现可能不在我们的数据库中。 HTTP API 也是如此。如果我们接受URI，我们就无法真正确定该资源来自哪里，也许它甚至不支持我们的媒体类型。

这可能不是您想要的。

产品背景

这就是所谓的“嵌套”。考虑一下 Java 代码，这相当于:

public interface Operator {
   ...
   Line createLine(String name, LineType lineType);
   ...
}

在 HTTP 中:

POST /operator/123/lines
{"name": "15B", "type": "BUS"}

即使运营商并不真正“拥有”线路，这也可能更合适。服务器可以检查重复行或类似的语义规则。

超媒体

如果您确实希望线路成为独立实体，则必须以某种方式引用运算符。 Id会引入耦合，但是提供URI太通用，那么唯一的解决方案就是引入表单。

正确实现这可能会更复杂。重点是使表单类似于 HTML 的表单。只需通过超媒体提供适合客户的选项即可。

类似这样的事情:

GET /lines
{"create": {
    "operator": {
        "type": "select",
        "values": [ ... ]
    }
 },
"lines": [ ... ]
}