使用 POST 数据的数组键或数组值的 RESTful api

Posted 2023-02-19

【中文标题】使用 POST 数据的数组键或数组值的 RESTful api

【英文标题】：RESTful api using array keys or array values for POST data

【发布时间】：2019-12-31 08:02:38

【问题描述】：

我构建了一个 RESTful api，我需要从前端获取复杂的数据。但我不确定应该为 POST 数据选择哪一个。

我应该获得路线组所有可能路线的价格。一个例子：有一条总线，它从端口 1 开始，到端口 2，并在端口 3 结束。我应该获取路线的每种乘客类型的价目表：

port-1 to port-2
port-1 to port-3
port-2 to port-3

我在考虑这两个选项。通过查看下面的示例数据，您将了解数据类型。

1-

prices: [
    
        departure_port_id: value,
        arrival_port_id: value,
        ticket_type_id: value,
        priceable_type: value,
        priceable_type_id: value,
        price: value,
        companion_price: value,
    ,
    
        ...
    
]

2-

prices: [
    departure_port_id-arrival_port_id: [
        ticket_type_id: [
            priceable_type: [
                priceable_type_id: 
                    price: value,
                    companion_price: value,
                
            ]
        ]
    ]
]

我不确定哪个更适合前端。

在第一个上，这看起来很清楚，但是有太多重复的数据，开发人员应该操作数据。或许可以设置data-属性为input，提交前应该在js端操作数据。

在第二个中，没有重复数据，全部按键分组，可用于输入的name 属性。喜欢：name="prices[1-2][1][passenger][1][price]"

你怎么看？还是你有更好的主意？

【问题讨论】：

你在控制前端吗？

@k0pernikus 是的，但我也应该考虑将我的 api 服务分享给其他人。

你想用 swagger 之类的东西来记录你的 api 服务吗？

@k0pernikus 是的，可能是邮递员或其他服务。我还没有搜索过。

我在回答中添加了一个提示，即在某些文档库中表达动态键不支持。

【参考方案1】：

这里没有正确和错误的答案，但主要归结为取舍：

是否需要让这些端点快速、流量少、“易于”使用？ （也许将这个端点拆分成一个专用的price/departurePortId/arrivalPortId 端点甚至是有意义的。）

根据您的用例，冗余平面方法也可能比嵌套对象更好，尤其是。如果客户需要 groupBy 一个不同的属性，因为这在平面阵列上实现非常简单。 （扁平化嵌套对象可能会成为一场噩梦。我去过那里。）

嵌套方法的一大缺点是它隐藏了元信息，所有这些 id：

departure_port_id-arrival_port_id ticket_type_id priceable_type priceable_type_id

仅用作它们的动态值作为（组合）键，如果它们是数字，则很难推断它们的含义。如果您要看到这样的响应，您将处理神奇的数字并且必须知道它们的意图。因此，如果您要使用嵌套方法，我仍然会将所有数据保留在最终对象中。

动态键的另一个缺点是它们很难在许多提供 api 文档的库中表达。 （例如，swagger 在表达动态键的概念时遇到问题，如果你想添加它，你可能需要重新定义你的模型。）

---

话虽如此：我会选择扁平化的响应。这可能取决于您的用例。

不过，我选择了一项更改，那就是对相关信息进行分组：

prices: [
    
        ports: 
            arrival: id: $value,
            departure: id: $value,
        
        ticket: 
            id: $value,
            type: $value,
        
        priceable: 
            id: $value,
            type: $value
        ,
        price: 
             amount: $value
        ,
        companion_price: 
             amount: $value
        ,
    
]

只有原始值的缺点是很难更改/添加新字段。在整个平面对象上，信息解析起来会变得很麻烦。 （假设您还想添加港口名称或价格货币。假设您对不同的定价信息有不同的货币。一个完整的平面响应可能会变成一个命名地狱，即：departure_port_name、arrival_port_name、@ 987654326@).

【讨论】：

感谢您的回答。我也有同样的想法。扁平化数据在后端有缺点。我想进行复杂的验证，以确保所有必要的数据都来找我。比如所有票种。我可以这样定义：你应该给我价格。78-90.1 数据。这不可读但易于定义。对于嵌套方法，首先我应该对数据进行分组并在验证它之后。不确定哪个很清楚，但我想我会采用扁平化方法。

@akcoban 我添加了一个建议，即在您的对象中包含对象，而不仅仅是原始值。

【参考方案2】：

我认为第一种情况是最好的。 你可以看看https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape。

【讨论】：

请阅读this 了解我为什么不赞成这个“答案”。

这里有一个正确的答案。不要只发布参考链接，还要引用其中最有意义的部分，以便此答案可以独立存在。