1

这个问题主要与如何使用 CRNK 框架执行此操作有关，但是我也将其标记为 JSON-API，因为我对这种方法在 JSON-API 规范的范围内是否普遍正确感兴趣。

我不想通过深入了解问题所涉及的确切领域的细节来使事情复杂化，所以我将稍微简化一下。

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

{ "time": "21/10/2018 10:15 GMT", "value": 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 的预期用途是各种屏幕将使用附加到队列的不同数据集，因此每个屏幕都有队列对象，然后可以通过这些关系链接请求它感兴趣的数据。

然而，我遇到的问题是，这里的历史数据不作为后端的可识别资源存在，仅作为队列的子资源存在（即 select * from historydata where 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 在很大程度上无关紧要？

4

1 回答 1

1

存储库的实现方式与 JSON API 规范关于如何处理关系的内容非常一致（请参阅 http://jsonapi.org/format/#crud-updating-relationships）。这意味着每个历史项目必须是资源，并且可以设置为与例如那些队列项目相关。因此，必须实施资源和关系存储库。关系存储库实际上只建立连接，并且它们本身不能处理数据。因此，只有资源存储库能够插入、更新和删除数据。

但是，在这个特定的用例（历史）中，使用关系存储库进行 GET 访问就足够了。使资源库成为可选（或至少将其隐藏在其余 api/crnk-home 中）不会太难。但它可能会稍微违反 JSON API 规范。

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

于 2018-03-29T14:41:39.250 回答