用 JSON API 表示无资源的聚合数据
Representing non-resourceful aggregated data with JSON API
我正在开发一个应用程序,我们正在研究使用 jsonapi 来描述所有 API 响应中的数据的可能性。它适用于类似资源的实体,但我们在想出一种以类似 jsonapi 的方式描述报告数据的方法时遇到了一些麻烦。
我所说的报告数据是指从我们存储在数据库中的基础资源类数据中动态聚合和计算的数据。例如,假设我们存储房地产信息,我们有关于房屋、公寓和办公室的信息 space,每个都与位置、属性 的大小(以平方英尺为单位)、类型 属性 相关联(无论是房子、公寓还是办公室 space),以及有关 属性 的任何其他相关信息。现在假设我们需要一个接收 ?group_by[]=location&group_by[]=type
的报告,并且我们希望响应传达关于这两个 group_by
参数的交集的聚合信息。因此,例如,我们会收到一个对象,其中包含给定位置所有属性的平均平方英尺面积,也按 属性.
类型分组
Average Property Sizes (in square feet)
Houses Apartments Offices
Manhattan 1234.56 234.56 123.45
Cape Coral 456.78 654.32 876.54
Portland 4321.00 987.65 2345.67
我们可以从这些数据中想到的最像资源的东西是每个单元格,但由于它们是更多基础数据的计算聚合结果,因此它们没有自然 ID。我们一直在考虑将它们与计算出的 ID 一起交付(可能将数据分组所依据的维度的 ID 结合起来,即 "house,34"
,其中 house
代表一种 属性 , 34
是位置的 ID "Manhattan")。然后每个单元将与相应的位置记录有关系,该记录将包含在有效负载的 included
部分中。这是一个示例 json 文件,它看起来像:
{
"data": [
{
"id": "house,123",
"type": "report_items",
"attributes": {
"property_type": "house",
"value": 108.75
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 123
}
}
}
},
{
"id": "house,124",
"type": "report_items",
"attributes": {
"property_type": "house",
"value": 36.0
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 124
}
}
}
},
{
"id": "house,125",
"type": "report_items",
"attributes": {
"property_type": "house",
"value": 1.0
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 125
}
}
}
},
{
"id": "office,123",
"type": "report_items",
"attributes": {
"property_type": "office",
"value": 4.0
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 123
}
}
}
},
{
"id": "office,124",
"type": "report_items",
"attributes": {
"property_type": "office",
"value": 2.0
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 124
}
}
}
},
{
"id": "apartment,123",
"type": "report_items",
"attributes": {
"property_type": "apartment",
"value": 2.0
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 123
}
}
}
},
{
"id": "apartment,125",
"type": "report_items",
"attributes": {
"property_type": "apartment",
"value": 4.5
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 125
}
}
}
},
{
"id": "apartment,124",
"type": "report_items",
"attributes": {
"property_type": "apartment",
"value": 2.0
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 124
}
}
}
}
],
"included": [
{
"type": "locations",
"id": "123",
"attributes": {
"name": "Manhattan"
}
},
{
"type": "locations",
"id": "124",
"attributes": {
"name": "Cape Coral"
}
},
{
"type": "locations",
"id": "125",
"attributes": {
"name": "Portland"
}
}
]
}
我的问题是:这是在 jsonapi 中表示此类数据的正确方法吗? jsonapi是否适合and/or推荐用于不直接映射到资源的数据?在自定义 json 中表示这些数据会更好吗?我知道这些问题中没有一个可能有明确的答案,但也许已经有一些关于如何处理类似场景、尝试使此类数据适合 jsonapi 等的利弊的经验。任何非常感谢评论和帮助。谢谢。
PS:即使在论坛和互联网上进行了一些挖掘之后,我还是发布了这个,这是我发现的仅有的两个链接,它们谈论的内容与我试图找出的内容相似,我也将它们包括在此处以供参考:
1.- http://discuss.jsonapi.org/t/composite-id-inside-the-resource-object/367/13
2.- http://discuss.jsonapi.org/t/extension-for-chart-graph-data/408
一般的答案是考虑哪些数据足够重要以保证您 API 双方的身份。我的意思是决定您以后要引用哪些内容或用关系表示哪些内容。 JSON API 允许您将这些东西定义为资源,并允许您将资源与更通用的 JSON 混合用于不透明的数据。
例如,也许 reports
以及您用来创建它们的选项和过滤器值得跟踪,以便客户可以通过其 id
请求重新查看同一报告。也许您想轮询您的服务器以查看正在创建哪些报告。
在客户端,您可能希望显示来自 property_type
资源的链接,以获取有关这些 属性 类型的更多信息。
或者,报告中的结果可能更好地表示为资源中 JSON 的 blob。 attributes
和 meta
可以包含任何类型的 JSON 值。
在您的特定情况下,您的主要资源可以是 reports
类型,或者 report_items
的数组,甚至可能是 property_summaries
与 [=18] 的关系的数组=] 和 locations
.
如果您选择更通用的资源类型,您可以概括报告过程,但您可能无法捕捉到数据的重要性。
如果您选择非常具体的报告资源,则需要真正自定义每种类型的报告,但您将能够在客户端的资源之间建立有意义的联系。
我正在开发一个应用程序,我们正在研究使用 jsonapi 来描述所有 API 响应中的数据的可能性。它适用于类似资源的实体,但我们在想出一种以类似 jsonapi 的方式描述报告数据的方法时遇到了一些麻烦。
我所说的报告数据是指从我们存储在数据库中的基础资源类数据中动态聚合和计算的数据。例如,假设我们存储房地产信息,我们有关于房屋、公寓和办公室的信息 space,每个都与位置、属性 的大小(以平方英尺为单位)、类型 属性 相关联(无论是房子、公寓还是办公室 space),以及有关 属性 的任何其他相关信息。现在假设我们需要一个接收 ?group_by[]=location&group_by[]=type
的报告,并且我们希望响应传达关于这两个 group_by
参数的交集的聚合信息。因此,例如,我们会收到一个对象,其中包含给定位置所有属性的平均平方英尺面积,也按 属性.
Average Property Sizes (in square feet)
Houses Apartments Offices
Manhattan 1234.56 234.56 123.45
Cape Coral 456.78 654.32 876.54
Portland 4321.00 987.65 2345.67
我们可以从这些数据中想到的最像资源的东西是每个单元格,但由于它们是更多基础数据的计算聚合结果,因此它们没有自然 ID。我们一直在考虑将它们与计算出的 ID 一起交付(可能将数据分组所依据的维度的 ID 结合起来,即 "house,34"
,其中 house
代表一种 属性 , 34
是位置的 ID "Manhattan")。然后每个单元将与相应的位置记录有关系,该记录将包含在有效负载的 included
部分中。这是一个示例 json 文件,它看起来像:
{
"data": [
{
"id": "house,123",
"type": "report_items",
"attributes": {
"property_type": "house",
"value": 108.75
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 123
}
}
}
},
{
"id": "house,124",
"type": "report_items",
"attributes": {
"property_type": "house",
"value": 36.0
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 124
}
}
}
},
{
"id": "house,125",
"type": "report_items",
"attributes": {
"property_type": "house",
"value": 1.0
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 125
}
}
}
},
{
"id": "office,123",
"type": "report_items",
"attributes": {
"property_type": "office",
"value": 4.0
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 123
}
}
}
},
{
"id": "office,124",
"type": "report_items",
"attributes": {
"property_type": "office",
"value": 2.0
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 124
}
}
}
},
{
"id": "apartment,123",
"type": "report_items",
"attributes": {
"property_type": "apartment",
"value": 2.0
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 123
}
}
}
},
{
"id": "apartment,125",
"type": "report_items",
"attributes": {
"property_type": "apartment",
"value": 4.5
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 125
}
}
}
},
{
"id": "apartment,124",
"type": "report_items",
"attributes": {
"property_type": "apartment",
"value": 2.0
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 124
}
}
}
}
],
"included": [
{
"type": "locations",
"id": "123",
"attributes": {
"name": "Manhattan"
}
},
{
"type": "locations",
"id": "124",
"attributes": {
"name": "Cape Coral"
}
},
{
"type": "locations",
"id": "125",
"attributes": {
"name": "Portland"
}
}
]
}
我的问题是:这是在 jsonapi 中表示此类数据的正确方法吗? jsonapi是否适合and/or推荐用于不直接映射到资源的数据?在自定义 json 中表示这些数据会更好吗?我知道这些问题中没有一个可能有明确的答案,但也许已经有一些关于如何处理类似场景、尝试使此类数据适合 jsonapi 等的利弊的经验。任何非常感谢评论和帮助。谢谢。
PS:即使在论坛和互联网上进行了一些挖掘之后,我还是发布了这个,这是我发现的仅有的两个链接,它们谈论的内容与我试图找出的内容相似,我也将它们包括在此处以供参考: 1.- http://discuss.jsonapi.org/t/composite-id-inside-the-resource-object/367/13 2.- http://discuss.jsonapi.org/t/extension-for-chart-graph-data/408
一般的答案是考虑哪些数据足够重要以保证您 API 双方的身份。我的意思是决定您以后要引用哪些内容或用关系表示哪些内容。 JSON API 允许您将这些东西定义为资源,并允许您将资源与更通用的 JSON 混合用于不透明的数据。
例如,也许 reports
以及您用来创建它们的选项和过滤器值得跟踪,以便客户可以通过其 id
请求重新查看同一报告。也许您想轮询您的服务器以查看正在创建哪些报告。
在客户端,您可能希望显示来自 property_type
资源的链接,以获取有关这些 属性 类型的更多信息。
或者,报告中的结果可能更好地表示为资源中 JSON 的 blob。 attributes
和 meta
可以包含任何类型的 JSON 值。
在您的特定情况下,您的主要资源可以是 reports
类型,或者 report_items
的数组,甚至可能是 property_summaries
与 [=18] 的关系的数组=] 和 locations
.
如果您选择更通用的资源类型,您可以概括报告过程,但您可能无法捕捉到数据的重要性。
如果您选择非常具体的报告资源,则需要真正自定义每种类型的报告,但您将能够在客户端的资源之间建立有意义的联系。