一个 create API 设计问题

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

This topic created in 654 days ago, the information mentioned may be changed or developed.

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

有两种设计方案：

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

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

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

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

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

create

API

Design

6 replies • 2024-07-17 22:49:16 +08:00

ounxnpz

Jul 17, 2024

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

Caratpine

Jul 17, 2024

@bluicezhen 不安全的点在哪里？

ounxnpz

Jul 17, 2024

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

supuwoerc

Jul 17, 2024

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

CLMan

Jul 17, 2024

你的设计方案，核心接口都是/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

Jul 17, 2024

@CLMan

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

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