REST API - 访问嵌入式资源的最佳实践

Question

我们使用 MongoDB，并提供 restful api 来访问资源（不仅仅是集合）。例如，我有一个设备集合。每个设备文档都有一个嵌套数组：运营商。这些是与运营商相关的关联类，没有任何唯一标识符。

{
   _id: ObjectId("..."),
   carriers: [
     {
         carrier: ObjectId("..."),
         bindingInterval: {
           from: ISODate("..."),
           to: ISODate("...")
         }
     },
     ...
   ]
}

在我们的服务中，载体绑定的独特性由特定字段的组合确定：载体+从+到值。

问题：最佳的restful实践是要求这些嵌入式文档吗？在许多情况下，我会单独地获取/发布/放置/删除它们。

否则，这只是一个例子。我们在许多其他情况下都有嵌入式文档。

想法： 1. 我在主资源ID下面的查询中单独描述复合参数。 2. 我使用这些参数的混合定义嵌入式文档的虚拟ID，并将此方法推广到类似情况。

- hasyee

---

说实话，如果您需要通过REST API查询特定资源，最好的方法是为其分配一个唯一的ID。如果您只需要对集合进行过滤，例如按from范围过滤，则某些资源查询语言将非常有用。 - Opal

后一种情况已经准备就绪，并且具有令人满意的查询语言，正如您所编写的那样。在前一种情况下，我认为不需要添加唯一标识符，因为指定的字段确保了唯一性。 - hasyee

完全同意，然而引入的ID将使查询更容易。 - Opal

因此，我想创建一个虚拟 ID ，以某种方式混合参数，例如简单的连接或 md5，并且不存储它，只用于查询。 我正在寻找restful教程中关于这个案例的内容，但我没有找到任何信息，然而它必须存在。 或者我错了，在端点结构的设计上犯了错误吗？ 为了安全起见，我希望API允许单独修改这些文档。这是一个不好的设计吗？我不知道... - hasyee

Answer 1

根据我的理解，您需要以RESTful的方式访问未分配任何ID的元素。

首先，我会为运营商添加一个单独的端点。它将是：

/devices/{deviceID}/carriers/

我不知道为什么在Mongo DB级别上不分配唯一ID（这似乎是最简单的选项），但如果不可能，最好通过路径传递人工复合键来引用给定资源，而不是通过查询字符串分别发送参数。因此，每次返回承运人集合时，为每个元素分配一个：

carrierID = md5(carrier+from+to)

使用此密钥，您可以轻松地通过以下方式引用每个嵌入式资源：

/devices/{deviceID}/carriers/{carrierID}/

似乎通过不同的端点引用这些资源将更容易。缺点是你需要在后端重新计算所有资源的carrierID，以检查是否有任何匹配接收到的ID。

我看到每个承运人字段都有一个ObjectId。它不是唯一的吗？为什么不使用它？

- Opal

---

/devices/{deviceID}/carriers/这是端点层次结构中的正确方式。 但是，md5需要在mongo端进行聚合，这必须计算每个md5值，正如你所说的那样。 carrierId在关联类中不是唯一的，因为同一运营商可能有不同时间段内的多个设备。 但我错了，from值对于查询是令人满意的。 - hasyee

所以如果“from”满足唯一性要求，我会将其用作“carrierID”。如果您不想显式传递它，请使用md5或其他哈希值 - 正如我已经写过的那样，这将影响性能。 - Opal

否则，如果我们有多个参数用于唯一性，则会出现问题。 但是！我不是在寻找解决方案。我需要最美丽和普遍接受的解决方案，如果有的话。 - hasyee

我会按照我建议的方式去做。 - Opal

如果你想在服务器端避免使用md5并且有唯一字段（如你所述的from），只需使用它即可。我所说的资源查询语言是RQL，它专为高级查询和资源过滤而设计。这也可能是一个有用的想法。 - Opal