编程语言是 Java 。 不知道弱类型的语言会有什么不同吗
POST /api/parse/message-type-a
POST /api/parse/message-type-b
每个 API 返回对应类型的 payload
POST /api/parse
请求体中带上 message type ，返回一个包装后的 payload
每个 type 返回的字段差别挺大的，type 现在有十来个，未来还有可能增加
POST /api/parse/message-type-a
POST /api/parse/message-type-b
每个 API 返回对应类型的 payload
POST /api/parse
请求体中带上 message type ，返回一个包装后的 payload
每个 type 返回的字段差别挺大的，type 现在有十来个，未来还有可能增加
 |
1
lwldcr 14 天前
我喜欢第一种 api 指向精准 下游处理也方便 不需要做类型判别啥的
当然如果前端需要在某个地方支持多种 payload 展示，那第一种估计就不满足或者比较难用了 |
 |
2
xiaohupro 14 天前
可以用路径参数来解决，例如你如果是使用 SpringBoot 的话：
@PostMapping("/parse/{messageType}") public CommResp parseByMessageType(@PathVariable("messageType") String messageType) { // 在里面根据参数 messageType 做具体的操作 } 不过如果只是根据消息类型获取内容，我建议使用 GET ，不过用 POST 也行，个人习惯问题 |
 |
4
8355 14 天前
我会选择方案 1 ，枚举值可以自定的情况下这个方案更好，资源型查询型接口可以更方便的套 cdn 等等，迭代风险也低，更加灵活，还可以通过路由做分流等等。
弱类型语言更习惯用方案 2 ，数据大多数来自于查表一套写完逻辑不变的话基本免维护。 |
 |
5
sankooc 14 天前
我个人喜欢第一种 后期做统计稍微简单一些
|
 |
6
liuhuihao 14 天前
[每个 type 返回的字段差别挺大的] ，根据这个我会选择方案一。如果一个接口，连自己内部返回的字段都不固定的话，维护起来会很困难，尤其是日积月累增加了多种类型之后。
|
 |
7
sagaxu 14 天前
如果能把 payload 类型统一化，放一个请求路径没问题。如果统一不了，最好还是拆分成不同的 API 。
|
 |
8
chendy 14 天前
放路径里
在 url 上多暴露一些东西有助于后面的分析统计和问题排查 |
 |
9
xuanbg 14 天前
没啥本质区别，我喜欢第二种，能少很多事
|
 |
10
HappyAndSmile 14 天前
第二种
|
 |
11
lijiangang886 13 天前
偏题：本着实用主义精神，一律 post ，不听那些把几十年前发明的 http method 的严重落后于当前时代的老古董语义当回事的意见
|
 |
12
AlexHsu 13 天前
我觉得得看 message type 有多少了 多就第二种 少就第一种
几十上百个 type uri 也太乱了 |
 |
13
837080606 13 天前
看功能，属于同一个功能就选第一个，相似代码多的选第一个。否则第二个。
如果不是相同功能里的，看着也麻烦。 相似代码少的，写 switch 其实和分开没啥区别，就是少写了个 URL 。 |
Select Language