是前端改还是后端改？

[OldCarMan]

rt,最近开发中，遇到某些情况，比如：

• 是返回一个 int 类型/状态等,前端去做逻辑判断（显示控制/渲染），还是直接返回一个字符串之类的结果（或者其他直接结果）给前端...
• 表单查询是统一用 post+raw,还是说简单的表单不需要 post ，requestBody ，只有复杂的表单查询才这样做？还是说只有新增/修改时，才会采用 post+raw 的形式...
• 当有一个需求/bug 改动，最好(性能，设计合理性等)是前后端配合着改时，是两边改，还是为了兼容，只改后端...

---

• 第一条，个人觉得，直接返回结果会带来几个问题：

1. 如果改数据必须存储到数据库中，会增加没必要的存储空间；
2. 增加流量，影响接口网络传输性能
3. 结果单一，如果需求改动，接口得增加返回更多得新需求数据，不能复用
4. 接口做过多的逻辑判断，会影响接口性能 当然这种问题无非是前端做还是后端做的问题，前端渲染时，去判断这些时同样需要消耗性能去执行。

• 第二条，个人觉得统一比较好，即使影响不大，但一会这，一会那的，写代码时的“注意”成本高（写接口时要去判断是用前者好还是后者好，用接口时要去看接口是前者那样用还是后者那样用）。。。

• 第三条，个人觉得前提是否具有兼容性问题，如果是有，当然兼容性是必须优先考虑的，不过兼容性可能要看改动影响的范围，如果影响较小，后端在原有基础上做兼容改动没啥问题，但如果改动较大，需要从版本上去做兼容，个人觉得此时前后端都得改，而不是某一方硬适配。当然如果没有兼容问题，建议怎么改，对主要的指标（性能，设计合理性，扩展性等）比较好就怎么来，无论谁需要改动。

---

PS: 哈哈，这里主要是最近一些经历，比如遇到一个问题需要改动时，同事总会说，这样前端需要改动之类的，让我尽量的去适配前端，让我怀疑是我的工作经历不足导致我认知不足，还是同事太顾着前端了😂,希望大家也留下平时前后端配合遇到的一些问题及解决方案，另外这里不是想挑起前后端对立，只是为了更好的认识问题及解决问题，大家尽管批评指正，谢谢大家回复！

[alleluya]

@vyronlee 确实 谁说话好使 谁就不想改

[mcluyu]

不知道你说的前端包不包含客户端，就第一条来说，这个字符串需要前端显示的话最好是直接返回， 除非这个显示不会改动不会增加。

因为客户端升级成本还是挺高的，APP 要审核通过才能上线，上线还要用户升级才能生效，增加修改了一种状态后旧版本 APP 就不能正确显示了。

另外可以抓包一些常见 APP 看看， 就拿京东来说， 它的接口返回的东西真是超乎想象的多，甚至一些按钮的 title 都是接口返回的，真就前端只负责渲染那种。

[dw2693734d]

我是后端，前端改！

[RoccoShi]

我是前端, 后端改!

[bojackhorseman]

状态值的话一般都是枚举 int 型吧

[alittlehj]

@doanything 是呀 我们公司前端都是妹子，经常就这样的问题跑你座位上跟你叽里呱啦说一堆 说什么这个我们前端不改 你们接口返回给我，我们不接受什么的，然后你想尝试说服她们的时候 你会发现磨破嘴皮子也没用。。。有这个时间不管是前端后端都早就改完了。。。。造成现在的后果是基本上后端接口能做的都是后端做了，现在等同于把饭嚼好喂她们嘴里

[bthulu]

前端不改, 后端也不改, 中台改就行了

[aababc]

我们的规则就是，如果是需要发版本的就让后端多干活，尽量让前端保持简单，容易修改。如果是不需要发版的就相对宽松一些，但也遵守前端尽量只负责展示，而不处理过于复杂的逻辑。

[pkoukk]

1.int
2.网关说了算，前后端都没资格说话
3.看需求，一般情况都是后端尽量兼容前端，因为前端开发周期太长了，发版窗口少

[awalkingman]

@dw2693734d
@RoccoShi 你俩打一架，谁打输了就谁改

[litchinn]

1. 返回 int ，如果只是为了显示，直接返回状态名也是可以的，大多数情况直接返回 int
2. 查询请求都是 Get ，不适合放在 url 中的参数就放在 header 里
3. 哪边改看设计，没有绝对，前端想让后端改或者后端让前端改得拿出理由，如果任一一边改都无所谓那么领导决定，因为要考虑的因素还很多，比如部署时间，部署影响的范围，开发周期等等

[nothingistrue]

作为一个干了超长时间的后端，给点经验之谈。

一、压根没必要去深究前端做还是后端做，因为绝大多数情况下，两边都可以做。如果不是两边都可以做，那么前后端就还不是两个端。

二、对于旧项目来说，优先遵循既往习惯。如果以前就是前端做，那就继续前端做，哪怕这次后端改着更省事。反之亦然。如果你不这么做，那么将来改 BUG 的时候铁定要吃苦头。

三、对于全新项目来说，以工作量平衡为目标，让前端、后端、总架构、项目经理先去协商，协商好了之后，继续优先遵循既往习惯。

[vikaptain]

1. 我个人习惯把值返回，再返回一个字符串字段标识该值的含义，前端爱怎么玩怎么玩。
2. 以前也搞 get/put/post/delete 区分， 现在直接全部 post 。瞎整那么多事干嘛啊。
3. 这个还是具体情况具体分析。根据实际情况做判断，拒绝教条主义
以上是项目没有要求的情况，有要求的情况下跟着项目要求走。

[yekern]

统一接收和返回, Web 接口返回和接收数据不管你是 json 还是 form POST 值全统一字符串, 有什么特殊需求自己管自己的 后端自己转类型格式化, 前端也一样

[lolizeppelin]

1. 用 int 节约带宽就是扯淡,字符串提高开发效率,一眼能看懂的状态用 int 还要想半天
如果后端状态 int 字段本身很多地方都在用了,才考虑用 int 表状态

2.说了 100 便了 了,用 http 重定向用 post 传 get 带 body 就完事

[lolizeppelin]

3. 后端接口都要都要带版本前缀/v1.0 方便更新修 bug,通过多版本接口实现兼容

[andyxic]

难道不是应该前端要什么，后端给什么。后端要什么，前端给什么吗？这种都不能算上体力活的东西，就是为了不想干找点借口吧

[zypy333]

考虑未来的变更，影响最小的一方改

[7inFen]

一些小问题，前端改完，打包+发布得 5 分钟左右，后端可能 5 秒？

[7inFen]

用户量大建议后端改，即时更新。前端改完发布还要刷新缓存，如果用户填了一堆表单提交时发现页面过期会崩溃的。