有人要求我查看正在处理的Node.js项目上的API响应扁平化,但是我不确定为什么需要对其进行扁平化。没有响应嵌套超过2个级别,因此对我来说还算不错。谁能告诉我为什么API响应会变平吗?我很想知道自己的优缺点,也希望听到关于它的建议吗?我目前正在查看npm软件包flat
。
这是一个示例响应:
{
"users": [
{
"id": 1,
"name": "John Doe",
"email": "john@doe.com",
"suppliers": [
{
"id": 1,
"name": "Supplier1",
}
]
},
{
"id": 2,
"name": "Jane Doe",
"email": "jane@doe.com",
"suppliers": [
{
"id": 1,
"name": "Supplier1",
},{
"id": 2,
"name": "Supplier2",
}
]
}
]
}
答案 0 :(得分:0)
有人可以告诉我为什么API响应会变平吗?我会 热衷于了解利弊,并听听有关如何 要做吗?
优点: 如果该API的使用者要求将其展平,则需要对其进行展平。例如,如果API的目的是提供将数据加载到某种形式的表视图中,那么如果API返回经过展平以匹配该表形状的数据,则对消费者来说将更加方便。>
缺点: 平整分层数据经常需要限制可返回的子元素的数量或创建更多有意义的行。
考虑通过以下两种方法对数据进行展平:
平淡无奇的方法#1
{
"users": [
{
"id": 1,
"name": "John Doe",
"email": "john@doe.com",
"suppliers_1_id": 1,
"suppliers_1_name": "Supplier1",
"suppliers_2_id": null,
"suppliers_2_name": null
}, {
"id": 2,
"name": "Jane Doe",
"email": "jane@doe.com",
"suppliers_1_id": 1,
"suppliers_1_name": "Supplier1",
"suppliers_2_id": 2,
"suppliers_2_name": "Supplier2"
}
]
}
在此示例中,必须提前确定可以退回的最大供应商数量。我确实不喜欢这种用于存储数据的设计,但是通常这是在表中显示数据的要求方式。例如,如果某个用户有3个供应商,那么您将无法在不添加更多列的情况下返回该数据。除非您的子行行数非常小且有限,否则它很快就会变得难以管理。
平淡无奇的方法#2
{
"users": [
{
"id": 1,
"name": "John Doe",
"email": "john@doe.com",
"supplier_id": 1,
"supplier_name": "Supplier1"
}, {
"id": 2,
"name": "Jane Doe",
"email": "jane@doe.com",
"supplier_id": 1,
"supplier_name": "Supplier1"
}, {
"id": 2,
"name": "Jane Doe",
"email": "jane@doe.com",
"supplier_id": 2,
"supplier_name": "Supplier2"
}
]
}
这种方法只是重复每个用户的供应商数量。这种格式很方便,可以将扁平化数据转换回分层数据。从单个行集中的关系数据库中检索层次结构数据时,这是一种常见的方法。客户端应用程序可以通过按用户ID分组轻松地重组原始层次结构。这种方法的缺点是,每个顶级对象返回多于一行的数据,这可能会导致更大的数据有效负载。如果您只有一个内部API使用者,则此方法可能有效。如果是用于公共API,则您将不得不花费更多的时间来记录和支持该API,因为这可能对您的API使用者没有意义。
我不确定为什么要弄平它。
无论谁要求您展平,都应指定他们正在寻找的实际形状,并且可以提供清晰度。我已经描述了两种可能的方法来展平您的数据,但是还有更多的可能性。