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