是前端改还是后端改？

[OldCarMan]

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

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

---

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

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

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

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

---

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

• 非常感谢大家的回复
• 个人比较赞同大家说的数据字典的形式；
• 小改动，改原有接口数据和字典；大改动，做版本兼容，路由切换？比如：/api/v1/
• 开发前定好规范，开发时做好统一。

另外一个问题： 大家接口响应是怎么样的，我看过这样的：

1.只用了基本的http code,用来判断网络或资源情况（比如2xx,3xx,4xx ,5xx等），业务的请求结果用响应的code表示(无论是否正常响应),比如:

{
  "code" : 200,
  "msg" : "success",
  "data" : {}
}

{
  "code" : 404,
  "msg" : "not found",
  "data" : {}
}

2.使用http code+data object和 error object的形式：

• 成功（http code=2xx）:

{
 data: {},
 info: {},
 messages: []
}

• 失败（http code=4xx）:

{
  "requestId": xxxxx,
  "status": 4xx,
  "message": "invalid xxx"
}

贴下谷歌云的接口谷歌云接口

[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]

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

[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]

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

[dudubaba]

都可以做，看谁话语权大，如果前端做，那后端在前端眼里就是 “sql boy”，如果后端做，前端在后端眼里就是“切图仔”。所以前后端要”紧密合作”，这样才能达到共同摸鱼的状态。