是前端改还是后端改？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 384 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

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

第二条，个人觉得统一比较好，即使影响不大，但一会这，一会那的，写代码时的“注意”成本高（写接口时要去判断是用前者好还是后者好，用接口时要去看接口是前者那样用还是后者那样用）。。。
第三条，个人觉得前提是否具有兼容性问题，如果是有，当然兼容性是必须优先考虑的，不过兼容性可能要看改动影响的范围，如果影响较小，后端在原有基础上做兼容改动没啥问题，但如果改动较大，需要从版本上去做兼容，个人觉得此时前后端都得改，而不是某一方硬适配。当然如果没有兼容问题，建议怎么改，对主要的指标（性能，设计合理性，扩展性等）比较好就怎么来，无论谁需要改动。

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

第 1 条附言 · 2023-11-19 01:06:06 +08:00

非常感谢大家的回复
个人比较赞同大家说的数据字典的形式；
小改动，改原有接口数据和字典；大改动，做版本兼容，路由切换？比如：/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"
}

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

改动

接口

兼容

post

41 条回复 • 2023-11-13 20:33:48 +08:00

GooMS

2023-11-13 04:59:18 +08:00 via Android

1. Int, 字典
2. get query

yigecaiji

2023-11-13 08:07:17 +08:00 via Android

我是前端，所以让后端改

fox0001

2023-11-13 08:14:45 +08:00 via Android

我的意见

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

qping

2023-11-13 08:17:00 +08:00

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

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

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

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

jazzg62

2023-11-13 08:22:33 +08:00

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

jucelin

2023-11-13 08:33:22 +08:00

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

darkengine

2023-11-13 08:45:03 +08:00

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

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

daydreamcafe

2023-11-13 08:48:33 +08:00

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

lsk569937453

2023-11-13 08:48:38 +08:00

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

darkengine

2023-11-13 08:51:26 +08:00

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

Selenium39

2023-11-13 08:55:23 +08:00

谁拿钱多谁改

cxshun

2023-11-13 08:58:13 +08:00

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

8355

2023-11-13 09:17:32 +08:00

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

vyronlee

2023-11-13 09:19:38 +08:00

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

LLaMA2

2023-11-13 09:26:06 +08:00

我来讲点道理,

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

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

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

skwyl

2023-11-13 09:33:48 +08:00

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

wu67

2023-11-13 09:35:39 +08:00

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

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

doanything

2023-11-13 09:37:51 +08:00

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

asmoker

2023-11-13 09:38:10 +08:00 via Android

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

ben1024

2023-11-13 09:47:02 +08:00

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

alleluya

2023-11-13 10:11:40 +08:00

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

mcluyu

2023-11-13 10:16:58 +08:00

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

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

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

dw2693734d

2023-11-13 11:00:22 +08:00

我是后端，前端改！

RoccoShi

2023-11-13 11:03:58 +08:00

我是前端, 后端改!

bojackhorseman

2023-11-13 11:16:11 +08:00

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

alittlehj

2023-11-13 11:24:40 +08:00

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

bthulu

2023-11-13 11:25:26 +08:00

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

aababc

2023-11-13 11:52:57 +08:00

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

pkoukk

2023-11-13 12:08:25 +08:00

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

awalkingman

2023-11-13 12:25:12 +08:00

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

litchinn

2023-11-13 14:36:25 +08:00

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

nothingistrue

2023-11-13 14:54:14 +08:00

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

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

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

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

vikaptain

2023-11-13 15:07:38 +08:00

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