是前端改还是后端改？

[OldCarMan]

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

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

---

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

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

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

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

---

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

[GooMS]

1. Int, 字典
2. get query

[yigecaiji]

我是前端，所以让后端改

[fox0001]

我的意见

1. 后端返回 int 。至于前端显示什么，怎么显示，后端不应该涉及
2. 如果接口不是用 json ，只能前后端商量，确定穿什么。如果用 post+raw ，最好是有清晰的文档。不推荐 get+请求参数。
3. 遇到需求/bug ，当然是根据实际去处理。我们一般是后端处理业务逻辑，前端处理显示和 UI 逻辑。

[qping]

1. 一般都是像一楼一样 int + 字典，减少网络传输的时间消耗更重要，int 传输的数据更少，速度更快。现在的浏览器和服务器增加个判断完全不是事情。

2. 这应该有统一的约定，合理的是 get,post,delete 都用上，但也有公司之前都是统一用 post ，那和约定保持统一是合理的

3. 前端应该是展示层，负责将数据渲染成界面，后端负责安全/校验/数据加载，运算，保存等等。
具体问题具体分析

我还是想说前后端不用卡的这么死，后端也需要学习前端的知识，前端也需要学习后端的知识。
但 jsp 那个年代，前端只是写写静态 html ，后端什么都做，现在前后分离，职责是单一了，但是更像是流水线工人，对于个人的成长是极为不利的。

[jazzg62]

我是前端，我直接改。除非领导要求后端改，或者前端改不了。

[jucelin]

1. 两个都返回，怎么显示前端自己决定；以后显示内容有小变化，后端一改就行；
2. 统一用 POST 最佳，前后端不用协商了；
3. 理论上后端要少改，后端会向多种前端提供数据，影响面比较大。

[darkengine]

3, 结果单一，如果需求改动，接口得增加返回更多得新需求数据，不能复用
-----------
如果你们有 app 端，这条刚好相反。如果 app 直接显示接口返回的字符串，如果需求改了(例如需要加个状态改变时间这种), 接口修改 app 不用发版。

不过这只是个例子，最终前端还是后端改得看具体的需求。

[daydreamcafe]

如果只是一条链路 后端->前端 ，那么哪边修改都能达到业务要求，无所谓。但是我想说后端没必要那样觉得所谓性能之类的不想修改，因为通常有些场景一些接口是要多端共用的，如果 web 、app 都依赖同一个接口，那么是不是要前端的开发修改 2 遍，能在后端确定的事情为什么要在前端修改

[lsk569937453]

1.返回 int
2.查询直接 get 就行啊

[darkengine]

@daydreamcafe 是的，我们之前赶鸭子上架的项目也是这样，接口怼原始数据回来，web/Android/iOS 都要对数据处理一遍才能用于展示

[Selenium39]

谁拿钱多谁改

[cxshun]

1. 如果是服务端之间对接，我的建议是直接用枚举，也就是字符串的方式，方式大家理解。如果是前端，那我建议是 Int 值，增加映射关系就好了。
2. 尽量遵循 RESTFUL ，新增用 POST ，修改用 PUT ，其他用 GET
3. 如果可能，尽量让后端接口保持原子性，前端来组合。所以，如果一个需求改动，前端可以通过组合来实现的，尽量前端来；如果不行，就服务端配合。

[8355]

1.int 控制渲染是前端自己的逻辑，后端不需要为了前端代码修改发版。
2.统一一个模式即可，协商解决，为了减少扯皮和不必要的沟通成本，全公司统一。
3.以现有需求和问题出发，最小代价解决问题为前提。

[vyronlee]

理论很完美，但实际情况基本都是：话语权小的一方改。

[LLaMA2]

我来讲点道理,

如果是网页这种的,前端动一下吧.
如果是 APP 这种还要走正规上架流程的,后端改一下也无妨。

还有，返回什么格式要始终遵循一样的规则，尽可能，谁都不能说那天没出什么差错。

友好协商，积极合作，共创共赢！

[skwyl]

同 1 楼
int + 字典
后台定义好字典给前端加载缓存就行

[wu67]

返回原始状态(存数据表里面那个), 映射关系写文档.

统一 post. 遇到过不负责任的家伙, 写文档完全复制, post get 不改, 导致每个接口是什么方式都要猜, 那不如干脆直接 post 算了, 还分什么 get put delete

[doanything]

基本上都后端搞。别说让前端搞。让前端改他就说只负责渲染。一顿拉扯还不如直接自己改了。

[asmoker]

问题②，有时候 b 端系统，查询条件很复杂，使用 get 方法单纯 kv 很难实现查询条件。get 传 body 也有坑，服务端有些框架直接把 get 请求的 body 擦掉了，默认拿不到。看阿里云有一个实现就是 get 方法 params=json 字符串这样，符合 get 语义，但是感觉怪怪的。post 不合语义，但是相对来说实现较简单。

[ben1024]

后端改，重心放在后端才能踢走前端