如何在没有顶级存储库的情况下在CRNK（JSON-API）中实现子资源关系

这个问题主要涉及如何使用CRNK框架实现这一点，但我也将其标记为JSON-API，因为我感兴趣的是，在JSON-API规范的范围内，这种方法是否通常是正确的

我不想通过讨论问题所涉及的具体领域而使事情复杂化，所以我将把事情简化一点

我有一个队列，它有各种属性，如名称、描述等。队列的另一个属性是一些历史时间戳数据，本质上是一个对象数组，看起来像：

{“时间”：“2018年10月21日10:15 GMT”，“数值”：35}

事实上，队列可以具有许多与该队列的不同数据相关的属性。阵列中的数据量可能很大，具体取决于收集的数据量

我的第一反应是在队列上对该属性进行建模：

{
  data: {
    ...
    attributes: {
      ...
      history: [
        { "time": "21/10/2018 10:15 GMT", "value": 35 },
        { "time": "21/10/2018 10:30 GMT", "value": 35 },
        { "time": "21/10/2018 10:45 GMT", "value": 35 }
      ]
    }
  }
}

然而，这种方法存在的问题是，整个数据集将随队列一起返回（队列可能非常大，并不总是必需的）。我可以通过使用稀疏字段集来解决这个问题，但我并不特别喜欢使用不同的字段参数一遍又一遍地请求队列，以便在特定场景中获取所需的数据

我想做的是将此历史数据建模为一种关系，这样可以通过关系URL访问数据，例如，

/api/queues/1/history

这对我来说似乎最有意义，因为api的预期用途是各种屏幕将使用附加到队列的不同数据集，因此，每个屏幕都有队列对象，然后可以通过这些关系链接请求它感兴趣的数据

但是，我遇到的问题是，此处的历史数据在后端不作为可识别资源存在，而仅作为队列的子资源存在（即，从historydata中选择*，其中queueid=1）。这就是我不确定如何在CRNK中实现它的地方。似乎要对关系建模，我还必须为子资源（/api/history/{id}）创建一个ResourceRepository。但我不想要这个

因此，关于CRNK实现，我的问题是如何配置我的资源和存储库，以便：

GET /api/history/{id} - always returns 404 (ideally without having to implement this myself in a HistoryResourceRepository)
GET/PATCH /api/queues/1/history - will go through the queue repository to access and update the history data using the queue ID as the identifier

---

另外，另一方面，如果子资源在这方面不作为可识别的实体存在，并且该ID基本上是不相关的，那么为子资源分配ID的推荐方法是什么？

存储库的实现方式与JSON API规范中关于如何处理关系的内容非常一致（请参见 )。这意味着每个历史记录项必须是资源，并且可以设置为与这些队列项相关。因此，必须实现资源和关系存储库。关系存储库实际上只建立连接，本身无法处理数据。因此，只有资源存储库能够插入、更新和删除数据

然而，在这个特定的用例（历史）中，使用关系存储库获取访问权限就足够了。使资源存储库成为可选的（或者至少在RESTAPI/crnk主页中隐藏它）并不太难。但它可能会稍微违背JSON API规范

---

如果您有多个历史记录，可以做的另一件事是使用嵌套的URL，如“history/queue”、“history/xy”，以建立一个干净的API，并将所有与历史相关的资源放在一个位置/子目录中。就我个人而言，我是在应用程序中这样做的。

我建议通过队列存储库来更新历史数据，而不是使用关系存储库来执行数据的任何插入/更新/删除操作，也就是说，补丁/queues/1/history将用于对历史数据进行更改，代码将保存在QueueRepository中，因为我们使用队列ID引用历史数据。如果我要走这条路线，使历史数据成为一种关系，并且必须为其实现一个存储库，如果数据仅通过队列ID引用，我将如何定义数据的ID？是的，当然，历史记录项不需要POST/PATCH/DELETE。如果单个队列项不在同一时刻更改两次，时间可能就足够了。