Question

这个问题主要涉及使用CRNK框架执行此操作的 HOW ，但是我还将其标记为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，其中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在很大程度上无关紧要？

Answer 1

实现存储库的方式与JSON API规范关于如何使用关系的内容强烈对齐（请参阅 http://jsonapi.org/format/#crud-updating-relationships）。意味着每个历史记录项必须是资源，并且可以设置为与例如那些队列项关系。因此必须实现这样的资源和关系存储库。关系存储库实际上只建立连接，并且可以通过它们来处理数据。因此，只有资源存储库才能进行数据的插入，更新和删除。

但是，在此特定用例（历史记录）中，使用关系存储库进行GET访问就足够了。使资源库可选（或者至少将其隐藏在其余的api / crnk-home中）并不是一件非常困难的事情。但它可能会略微违反JSON API规范。

如果你有多个历史记录，可以做的另一件事就是利用“历史/队列”，“历史/ xy”之类的嵌套网址来建立一个干净的API并拥有所有与历史相关的资源一个地方/子目录。我个人在应用程序中这样做。

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

1 个答案: