一个 create API 设计问题

[Caratpine]

现在要设计一个 create API ，这个接口有 a, b, c, d, e 四个字段，d 的值可以根据 a 来设定, e 的值可以根据 a, b 两个组合来设定。

有两种设计方案：

1. 只设计一个 create API ，可以让用户传 a, b, c, d, e 所有值，也可以只传 a, b, c, 接口自己处理得到 d, e.

2. 设计三个接口:

• /create 只用于接收用户传的 a, b, c, d, e, 用户传什么就是什么。
• /get_d 用来得到 d
• /get_e 用来得到 e

拿到所有结果再去调用 /create

两种方案，你会选择哪种？请尽可能多得提供一些业务场景。

或者有没有更多的方案？欢迎讨论👏

[ounxnpz]

1 啊，2 不但不安全，写起来也更复杂。

[Caratpine]

@bluicezhen 不安全的点在哪里？

[ounxnpz]

@Caratpine 用户可以随意编造一个 d, e 的值。在一些场景下，这被认为是不安全的。

[supuwoerc]

前端传啥就是啥，自己校验一次是不是就行了?

[CLMan]

你的设计方案，核心接口都是/create ，而且参数列表也是一致的，我没看出来有什么本质区别。

你的表述有些混乱，我帮你理清一下：

- 如果 d,e 是完全由用户决定，那为什么提供/get_d,/get_e ？

- 如果 d,e 由后端生成，用户选择，那提供/get_d,/get_e 是必然选项。

- 如果 d,e 完全由后端生成，那为什么提供/get_d,/get_e ，只需要参数列表 a,b,c 就行了，后端自己调用 get_d,get_e 。

[CLMan]

@CLMan

我推测你想表达的是，方案一强调 d,e 是可选参数，方案二强调 d,e 是必选参数。

我推测你想描述的场景是：d,e 可以完全由用户决定（后端只检查值的合理性），或者由后端提供值。
那通常是选择方案一，因为更简单，没必要多两个接口出来，对用户来说使用更加复杂。