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

Question

我构建了一个RESTful api，我需要从前端获取复杂的数据。但我不知道我应该选择哪一个作为发布数据。

我应该知道路线组所有可能路线的价格。举个例子:有一辆公共汽车，从端口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-属性设置为输入，并在提交之前对js端的数据进行操作。

在第二种情况下，没有重复的数据，它们都是按键分组的，并且可以用于输入的name属性。喜欢：name="prices[1-2][1][passenger][1][price]"

你对此有什么看法？还是你有更好的主意？

Answer 1

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

是否有必要让这些端点快速、轻流量、“容易”使用？(也许将这个端点分割成一个专用的price/departurePortId/arrivalPortId端点甚至是有意义的。)

根据您的用例，冗余平面方法也可能比嵌套对象更好，尤其是。如果对客户端的需求出现在groupBy上，那么在平面数组上实现这一点是非常直接的。(使嵌套对象变平可能成为一场噩梦。我去过那里。)

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

• {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、companion_price_currency)。

Answer 2

我觉得第一个案子最好。你可以看看https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape。