RESTful api 对 POST 数据使用数组键或数组值
RESTful api using array keys or array values for POST data
我构建了一个 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]"
你怎么看?或者你有更好的主意吗?
我认为第一种情况最好。
你可以看看 https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape .
这里没有正确和错误的答案,但主要归结为权衡取舍:
是否需要让这些端点速度快、流量少,"easy" 才能使用? (也许将此端点拆分为专用的 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
, companion_price_currency
).
我构建了一个 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]"
你怎么看?或者你有更好的主意吗?
我认为第一种情况最好。 你可以看看 https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape .
这里没有正确和错误的答案,但主要归结为权衡取舍:
是否需要让这些端点速度快、流量少,"easy" 才能使用? (也许将此端点拆分为专用的 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
, companion_price_currency
).