前端请教 后端返回数据格式问题

[HeroYang811]

本人：前端
对方：后端(外包)
情况：电商项目首页商品列表
问题 1：在多维数组内某些字段含有多个数据的情况下，后端返回的数据格式为字符串，多个则用逗号隔开比如"http://123,http://456,http://789"，然后让我前端去做逻辑处理，也就是说让我将字符串转换为数组再处理。
问题 2：部分类型判断采用中文，比如某个商品类型，name === '类型一号' ，然后根据这个相等的类型去展示对应的内容。
我的前端理解：这也太不规范了吧，很多地方逻辑数据处理全部扔到了前端,而且是在商品首页数据量这么大的地方，难道不会导致页面渲染缓慢吗，并且说：“客户端处理逻辑是用户体验感最好的表现”，偷懒也不能这样吧
结果：浪费时间，我懒得扯了，前端写就写吧

虚心请教，各位后端大牛的看法，

[wu67]

第一个问题, 其实谁干都行, 典型的用 mysql 存字符串, 只是他懒得分割而已 (换 pg 存数组就简单粗暴了, pg 大法好). 前端分割其实没太大问题, 累点而已, 你的商城是小程序那就另说, 那玩意的性能和屎一样.

第二个问题, 一言难尽, 很多老旧系统都有, php 的各种商城就是重灾区, 大概是从他的旧代码库里面 c v 了...

[xuelu520]

部分简单的拆装拼接逻辑给前端，可以降低后端压力。(前端性能都这么强了，这点不算啥)
一般列表都是分页来的，如果数据量大，应该要考虑需求是不是有问题。
总之看你们有没接口规范，没有就怎么合作舒服怎么来

[cat]

特别讨厌用逗号 , 来隔开的，一旦值本身包含逗号，一分割就乱了

[gxy2825]

你们公司前端也太好说话了吧，换我们给前端这样的数据早就炸了
op 或许可以问问前端/后端组长的意见？或者其他老员工

[awalkingman]

@cat 我是特别害怕

[gitrebase]

问题 1：就像 #1 说的，很有可能是在存“一对多”的数据的时候不想新建一张表，按我的习惯我是会在后端把数据转为数组再传递给前端的

问题 2：用中文 emm 我也不知道行不行，但是用 code 会更好吧

[brader]

还算正常，我理解是都可以。
还有你说性能的问题，其实影响不大，如果你非要比较个高低，我觉得放服务端转化影响大，因为服务端要面对所有客户端。

[Bingchunmoli]

@brader 赞同，1. 是需不需要单独处理，前后端都能做的事 看分工，2. 一般用 int ， 不排除一些政企或者老系统喜欢中文需要兼容或者什么的， 数据的一些逻辑处理是可以后端和可以前端的，从性能考虑 优先前端，前端性能“无限”, 还有一种考虑是 后端一个接口支持多端，不同端对应自己业务自己处理， 如果单端，服务器并发不高，前后端都行

[James2099]

我也遇到过，筛选 list 列表都让我自己前端写死，还有分页前端来做，还有返回的数据格式，也要我分割，明明穿一个对象就能解决

[1016]

你这算啥... 我这边后端返回的数据像 tmd 一坨屎... 明明他自己能处理的数据 非要丢给我来处理 自己坐在那里玩手机 刷推特 我真的 C™D

主要他也玩 v2 也不好把数据粘贴出来。

[k9982874]

这。。外包你不干他，留着他过年？

[wdf]

那你是没遇到我们的后端，前端用的级联组件，按道理后端返回正常的树结构就没啥问题，结果他返回的数据每层的数据格式不一样，层级也不确定 说最多 5 层，最多返回 5 千多条数据，沟通让改下数据格式，后端回怼句：我返回的数据格式是有意义的，我修改的话不太好。我现在有点质疑自己 不知道问题出在哪了

[sanmaozhao]

1 、既然是多值，那就以数组返回
这个没什么好商量的，后端你爱咋存咋存，不要暴漏给前端。更别说值里面有逗号咋办的事儿了

2 、逻辑判断用中文不太好，或者说不要用“会显示到界面上的值”
因为会显示出来的，后续很大可能就要修改，文案啥的谁都没法保证不变
如果这个中文永远不显示给用户，那就还行吧，你就当它是个 key 好了

[nothingistrue]

如果单纯从技术层面讲：
问题 1 ，前后端谁做都可以，后端的视图层，前端的 Model 层都是干这事的，至于具体谁做，首先要看以前谁做，其次要看现在谁愿意做，最后才是看谁有时间做。
问题 2 ，不与代码同步的文档不如没有文档，没有管理的编码不如直接用名称。尤其是经过大数据分析的发展之后，那种没用的编码，还是让他步入坟墓吧。

实际上你不要扣技术，没意义。

[davin]

感觉第二个问题可以用 enum 枚举映射， 用的时候，name === ItemTypes.Category1 这样判断。之后维护这个 ItemTypes 就好，减少传说中的魔法值。其他比如订单状态，衣服的尺码 (M 、L 、XL 、XXL 、XXXL 等)，订单审核状态也适合用枚举。

[MoYi123]

喷点只有
1. 不规范
2. 逗号不在 url 转义的表里, 一定要这样搞用个分号, 保证不切错(包括后端的存储)

硬要说性能, 我猜这样 split 性能会比解 json 更好.

[MorJS]

上嘴脸

[FawkesV]

问题 1 偷懒了. 也确实很丑.
问题 2 看业务场景,有没有 code 实在没办法只能这样子处理了

[coderzhangsan]

1 谁做都行，只是看谁懒得强势些，你来提问，就应说明问题了；至于性能，你说得太夸张，你一页要显示多少商品数据？几百条以下，字符串转换为数组能耗损什么性能。
2 用中文可能是前期设计遗留的问题，加状态枚举估计要改造库表，能跑就行，不必过多关注，真有问题，推给后端就好了。

总结：
1 你有代码洁癖
2 贵司后端比较强势
3 后端外包，你们的项目估计也好不到哪去，所以程序和程序员只要有一个能跑就行

[fkdog]

后端水平太次了，英文半角逗号是 url 无需转义的字符，但凡哪天 url 需要存一个云厂商处理过的带参数图片、视频（往往 url 里带半角逗号的），就会出问题。

[nice2cu]

估计数据库里就是这么存的，不存成 json 格式迟早要炸

[kristofer]

第一个问题，后端菜，不过你都说他是外包了，菜很正常。谁来解析都跟性能没关，一个分页列表，有啥性能问题。
第二个问题，历史遗留的不算，新代码且不是非这样不可的情况下，采用中文判断我不认可。

[zjyl1994]

1 的话，确实应该后端处理，存储层的细节不应该暴露出来给到前端。
2 的话和业务有关，有些上古系统就是这么设计的，你不兼容搞两套维护成本更高。而且很有可能接口已经被其他部门拿去用了，只能将错就错继续用下来，等接口重构才有机会改。

[ntedshen]

逗号拆数组的逻辑中间件写就完了吧，哪端都一样。。。

“很多地方逻辑数据处理全部扔到了前端,而且是在商品首页数据量这么大的地方，难道不会导致页面渲染缓慢吗”
讲道理前端苛求性能然后让后端做处理才更不符合现实逻辑。。。
尤其国服硬件性能本来就卷的很，一个电商客户端/网页还能有两位马老板的全家桶费性能？

[Shosuke]

我也碰到過這樣的後端，開發體驗糟糕的不行。

很多的事情邏輯上都扔到了客戶端，還有前端總要因爲後端的數據無規範，寫出一大堆自己看了都想吐的代碼。

不管怎麽溝通都會出現同樣的問題，最後自己選擇辭職。

[Shosuke]

問題 1 ）數據不是很多的話，可以接受，但是這種傳 string + ',' 方式真的不太好。
問題 2 ）專案是因爲太老了要維持字典還是什麽原因，好想吐槽...

[bthulu]

部分类型判断采用中文有什么问题? 我这边工业领域, 大部分专业名词都没有英文, 难道你还去生造一个英文单词出来?

[snarkprayer]

歪个楼，针对页面渲染缓慢这个，前端大部分项目其实摸不到性能瓶颈，看着不流畅一是动画不够，二是 HTML 历史包袱太重，抛弃掉各种兼容的话性能翻个一两倍轻轻松松

[looo]

我看前排好多人觉得这种逻辑后端没必要去写，都前后端分离了，那是不是先出文档，根据文档要求只做展示，前端不做任何业务处理。

一句话：前端只做展示，不做任何业务处理。

[IvanLi127]

问题一，绝对是后端偷懒，这都不转换回多维数组，要前端再处理，那要这后端有啥用？要我就直接拉他项目改代码了。
问题二，不好说合理不合理，如果是类似字典表做动态类型的话，中文就中文吧。

[bianhui]

针对问题 1：可能数据库存的就是字符串。后端拿到之后直接吐了，就没有处理。站在后端角度看，split 是要损失性能的，而这些性能是公司的服务器提供，都是要公司花钱的，如果 split 在客户端，用的是用户资源。其次众所周知处理成 json 会包含大量的无效字符，比如说引号逗号，在高并发常见会造成带宽的更多占用。
在前端角度看，确实破坏了整个项目统一性和规范性。让项目维护起来困难。同时如果后端数据格式发生变动，前端必须要跟随修改。
总结：如果公司不是你的，你自己分一下得了。
针对问题 2：这个不用说后端问题，可以让对方规定一套枚举或编号用于判断，中文在不同环境下编码有问题是毋庸置疑的。
总结：你可以让后端试试表单提交的 field name 全是中文的感觉

[wangtian2020]

其实逗号分隔的结果和 ['http://123','http://456','http://789'].join() 的执行结果一致
不能说完全没有关系，但是还是在返回体里面用 json 比较好

更坑的后端是直接返回个破字符串要求你 JSON.parse 几下

[duanxianze]

刚开始工作的时候我还会争辩两句，现在没必要，小公司，一来领导是看你工作时间给钱，二来你费劲心思写的代码说不定坚持不到 1 年就没用了，尤其是前端代码，说什么可维护都是扯淡

[wolfie]

经历不同，我们公司前端要求逗号更多，后端给数组时 老让后端改。

[i8086]

不排除就是直接从数据库读取出来，也不转换，直接返回给前端了。

[luliumytime]

能用就行

[SleepyRaven]

前后端都写一点的说下个人看法：
1 、这个存储的时候，避开值本身包含逗号或者转义的情况下，用逗号隔开存整个字符串也是可以的，问题在于返回给前端的时候肯定要 split 成数组的。
2 、这肯定不行啊，枚举值要么接口返回要么前后端统一写到常量 map 里。

[abcdexx]

@1016 在网上挂我？好，我记住你了。

[darkengine]

@Shosuke 是的，为了展示数据要做转换，特别是 web 转一遍，Android/iOS 又要转一遍。

[x2420390517]

既然是外包的，那肯定是你说了算

[xujiang]

@wdf 这么多数据，前端一次性渲染可能会崩掉，😄

[brader]

@cat
@fkdog 按标准做的 url ，是不会有逗号问题的
https://datatracker.ietf.org/doc/html/rfc3986

[cat]

@brader 我说的特别讨厌用逗号分隔，不限于楼主的例子，而且就如楼上说的，这是后端存储的方法，不应该暴露给前端处理，至少我自己写的接口都是用 [ ... ]

[brader]

@cat 这个存储方式我认为各有优劣，还有此种存储方式也没什么敏感点，所以无所谓暴露不暴露存储方式的问题。
还是回到类似数据场景，应该前端还是后端处理的问题，这种问题如果在公司没有明确指导方向，我觉得就是都可以，这个对前后端都不难。技术不要过于恪守教条，代码也有交流的人情世故吧。

[supuwoerc]

对面是个懒狗，直接让他改，强硬点。

[youngwen]

第一个问题，自定义的分隔符应当由后端处理，前端应当无感，将这个分隔符的影响最小化。
第二个问题，本质上是没有找到合适的抽象定义

[sankooc]

第一个问题需要跟他们说好风险点比如字符串本身有分隔符的情况 第二个其实没有办法 毕竟是外包不好追求完美

[cfancc]

第一个问题后端处理
第二个问题，定义一套枚举值，而不是用 name

[ma836323493]

@wangtian2020 #32 所以返回 json 字符串有什么问题，你存的什么我返回什么， 这种存多个链接不至于再建表

[passon]

感觉 1 ，2 都不是什么问题

[konakona]

问题 1：问题倒不是特别大，要看你们团队对于“前后端数据通信”有没有约定的文档，很难说一个前端去要求后端提供什么样的数据是合理的。因为只有后端自己知道加领域去处理回传数据为数组的开销是多少，并不完全是偷懒的问题。
问题 2：取决于公司团队规模，如果是小规模，为了快速交付，那建议是后端提供字典接口，方便前端枚举；如果是小规模以上，那就应该规范做事，可以由前端跟后端约定好字典后，在前端维护本地字典。好处是经过大家敲定拍板的东西，如果一方改动造成迭代问题，可以通过字典追溯出是后端私自改了还是前端私自改了。

[wangtian2020]

@ma836323493 对对对，数据不用处理，把整个数据库都返回给前端。后端开了吧

[wangtian2020]

@ma836323493 见过前端请求时 json 是一个字符串的吗，水平低数据不会处理找那么多理由。怎么处理需不需要建表不是前端要考虑的事情。接触过有些后端是真的过分，接口设计到处搞些技术倒退的莫名其妙的地方，最后一整个系统都是一坨。我提交数据的时候还是好好的一个 json ，返回一个字符串什么意思“Json 序列化与反序列化”不会就去学一个

[hongjijun233]

@1016 #10
在网上挂我？好，我记住你了。

[romisanic]

1 看数据提交的时候谁拼接的，如果是后端拼接的，那就后端去解，如果是前端拼接的，前端去解。
2 有历史包袱的话也常见，但是新功能新枚举的话不应该，改。

[ma836323493]

@wangtian2020 #53 一个表单提交，n 个附件，但是这些附件没有业务逻辑查询是可以 json 字符串存储的，如果单独建个附件表的话，修改，删除都需要删除关联附件表来重新新增。而且 新增的时候前端可能传[url], 后端查询详情的 返回不处理的话就是 list 对象 [{url,id}]

[brader]

@wangtian2020 阿里云和腾讯云的 API 一样出现很多图片字段，通过逗号或者分号分隔的字符串返回，json 字符串直接返回。
按你说的，他们的工程师也是低水平的，可以开掉了

[kamilic]

多年工作的体会，关于前后端对接格式这些东西，我觉得这是话语权的问题，没有规范约束的情况下就看谁能说服谁，也可以说谁先妥协。
遇到赖皮的前/后端，如 OP 举的例子，好说话的一方总会妥协地处理掉了。
除非你直接摆烂说不按照需要的返回我就不干了，把问题往上反馈也是一样看主管方的话语权大。

说到底还是要有规范，而且还要不断根据不同对接场景迭代的规范。

[kamilic]

前端在研发链条末端，往往话语权更低，毕竟一般概念上都是没有后端接口不行。
但链条反过来也不是不行，只要前端写的屎山够大，改不动了也能翻转驱动后端对接前端（狗头

[xingdaorong]

第一个问题前端和后端处理都是一样的，后端返回这种类型字符串，直接说没有语义化，数组就是数组，字符串是字符串，除非给一个特别理由，比如接口会慢几秒，其它不接受

[evam]

找前端组长/后段组长/架构师
这种事情其实看编码规范

[2324]

@James2099 前端做分页是一次性传个 1 ，2M 的数据，自己拿 js 裁吗？

[James2099]

@2324 对的

[wangtian2020]

@brader 确实是水平不高，也就 java boy 老是搞这种接口了，要是 nodejs 当后端绝对不可能有 json 字符串出现在接口里面。存可以存 json 字符串，处理成 json 对象再传出来可以吗

[OrionParker]

@1016 在网上挂我？好，我记住你了。

[brader]

@wangtian2020 别人这么搞自然是有道理的，这些字符串存在一个数组记录里面，服务端反序列化需要成本，对于一个请求来说微不足道，但是成千上万个请求就有的算了，把这部分算力下放到客户端也没什么不妥。
另外像微信之类，近些年他们也把很多服务端可完成的算力成本下放到客户端了，很多计算都在客户端做。

[wangtian2020]

@brader 我作为对接方是不是还得夸他几句？
主题里是普通的前端和后端对接接口，反正我遇到的后端给出这种接口我肯定要骂。哪怕真是去对接阿里腾讯 api ，他好意思给这种接口我作为对接方难道得夸他几句？

[brader]

这本身就是不同角度看法产生的矛盾点，如果你能夸对方的话，矛盾也就不存在了。
我只是说从技术上讲这种做法我认为没什么问题。
非要解决这个争议也很简单，有决定权的人提前把规范定下来就是了，开发遵照执行。

[way2create]

我说句实话，哪怕就算是他不规范他菜但你没话语权有啥用呢？很多事实际工作中是商量着来的，只要不会太离谱就行，而且很多规范遵守不遵守说实话也看公司看项目看工期，不是谁都是搞得高大上的。

[morenacl]

通常不都是前端外包，后端自己搞

[way2create]

补充一句：
1 这个非要说规范肯定是不太推荐这样存的 但有些实在是小项目没要求的或者历史遗留问题也懒得去动 其次这种数据一般只会考虑本身没有逗号的数据
2 这个我不喜欢用中文判断
我实际工作中一般都跟前端商量着来，我多做点事也无所谓，只要不会太离谱工期允许，鄙人也是底层 CURD BOY 不是什么大牛，个别前端(仅针对我遇到的来说)真的是又菜又爱偷懒，你要是说帮我处理下我也 OK ，还非要把人当傻子扯 7 扯 8 装 X ，实际上规范也不是他那样的，项目也是个极小的项目，真的就啥逻辑验证都不乐意写只管发送接收就好。

[soloHm]

@gitrebase 问题 2 正常要么定义成字典要么定义成枚举，但是直接用名字 确实不咋地