时间戳

首页 > 解决方案 > 为什么在 Node 应用程序中扁平化 API 响应

javascript - 为什么在 Node 应用程序中扁平化 API 响应

问题描述

我被要求查看我正在处理的 Node.js 项目的扁平化 API 响应，但我不完全确定为什么需要扁平化它。没有响应嵌套超过 2 个级别，所以对我来说还不错。谁能告诉我为什么 API 响应会变平？我很想知道利弊以及听到有关如何做到这一点的任何建议？我目前正在查看 npm package 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",
               }
           ]
       }
    ]
}

标签： javascriptnode.jsrestapi

解决方案

谁能告诉我为什么 API 响应会变平？我很想知道利弊以及听到有关如何做到这一点的任何建议？

优点：如果 API 的使用者要求将 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 使用者没有意义。

我不完全确定为什么需要将其展平。

无论谁要求您将其展平，都应指定他们正在寻找的实际形状，这可能会提供清晰性。我已经描述了两种可能的方法来扁平化你的数据，但还有更多的可能性。

推荐阅读