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

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

虚心请教，各位后端大牛的看法，
8417 次点击
所在节点    程序员
72 条回复
xujiang
2023-12-12 10:43:00 +08:00
@wdf 这么多数据，前端一次性渲染可能会崩掉，😄
brader
2023-12-12 10:53:45 +08:00
@cat
@fkdog 按标准做的 url ，是不会有逗号问题的
https://datatracker.ietf.org/doc/html/rfc3986
cat
2023-12-12 10:59:15 +08:00
@brader 我说的特别讨厌用逗号分隔，不限于楼主的例子，而且就如楼上说的，这是后端存储的方法，不应该暴露给前端处理，至少我自己写的接口都是用 [ ... ]
brader
2023-12-12 11:06:25 +08:00
@cat 这个存储方式我认为各有优劣，还有此种存储方式也没什么敏感点，所以无所谓暴露不暴露存储方式的问题。
还是回到类似数据场景，应该前端还是后端处理的问题，这种问题如果在公司没有明确指导方向，我觉得就是都可以，这个对前后端都不难。技术不要过于恪守教条，代码也有交流的人情世故吧。
supuwoerc
2023-12-12 11:54:36 +08:00
对面是个懒狗，直接让他改，强硬点。
youngwen
2023-12-12 12:28:58 +08:00
第一个问题，自定义的分隔符应当由后端处理，前端应当无感，将这个分隔符的影响最小化。
第二个问题，本质上是没有找到合适的抽象定义
sankooc
2023-12-12 13:37:50 +08:00
第一个问题需要跟他们说好风险点比如字符串本身有分隔符的情况 第二个其实没有办法 毕竟是外包不好追求完美
cfancc
2023-12-12 13:44:13 +08:00
第一个问题后端处理
第二个问题，定义一套枚举值，而不是用 name
ma836323493
2023-12-12 13:47:06 +08:00
@wangtian2020 #32 所以返回 json 字符串有什么问题，你存的什么我返回什么， 这种存多个链接不至于再建表
passon
2023-12-12 13:48:47 +08:00
感觉 1 ，2 都不是什么问题
konakona
2023-12-12 14:27:05 +08:00
问题 1：问题倒不是特别大，要看你们团队对于“前后端数据通信”有没有约定的文档，很难说一个前端去要求后端提供什么样的数据是合理的。因为只有后端自己知道加领域去处理回传数据为数组的开销是多少，并不完全是偷懒的问题。
问题 2：取决于公司团队规模，如果是小规模，为了快速交付，那建议是后端提供字典接口，方便前端枚举；如果是小规模以上，那就应该规范做事，可以由前端跟后端约定好字典后，在前端维护本地字典。好处是经过大家敲定拍板的东西，如果一方改动造成迭代问题，可以通过字典追溯出是后端私自改了还是前端私自改了。
wangtian2020
2023-12-12 14:33:47 +08:00
@ma836323493 对对对，数据不用处理，把整个数据库都返回给前端。后端开了吧
wangtian2020
2023-12-12 14:43:03 +08:00
@ma836323493 见过前端请求时 json 是一个字符串的吗，水平低数据不会处理找那么多理由。怎么处理需不需要建表不是前端要考虑的事情。接触过有些后端是真的过分，接口设计到处搞些技术倒退的莫名其妙的地方，最后一整个系统都是一坨。我提交数据的时候还是好好的一个 json ，返回一个字符串什么意思“Json 序列化与反序列化”不会就去学一个
hongjijun233
2023-12-12 15:55:40 +08:00
@1016 #10
在网上挂我？好，我记住你了。
romisanic
2023-12-12 16:30:49 +08:00
1 看数据提交的时候谁拼接的，如果是后端拼接的，那就后端去解，如果是前端拼接的，前端去解。
2 有历史包袱的话也常见，但是新功能新枚举的话不应该，改。
ma836323493
2023-12-12 17:00:08 +08:00
@wangtian2020 #53 一个表单提交，n 个附件，但是这些附件没有业务逻辑查询是可以 json 字符串存储的，如果单独建个附件表的话，修改，删除都需要删除关联附件表来重新新增。而且 新增的时候前端可能传[url], 后端查询详情的 返回不处理的话就是 list 对象 [{url,id}]
brader
2023-12-12 17:17:01 +08:00
@wangtian2020 阿里云和腾讯云的 API 一样出现很多图片字段，通过逗号或者分号分隔的字符串返回，json 字符串直接返回。
按你说的，他们的工程师也是低水平的，可以开掉了
kamilic
2023-12-12 17:46:47 +08:00
多年工作的体会，关于前后端对接格式这些东西，我觉得这是话语权的问题，没有规范约束的情况下就看谁能说服谁，也可以说谁先妥协。
遇到赖皮的前/后端，如 OP 举的例子，好说话的一方总会妥协地处理掉了。
除非你直接摆烂说不按照需要的返回我就不干了，把问题往上反馈也是一样看主管方的话语权大。

说到底还是要有规范，而且还要不断根据不同对接场景迭代的规范。
kamilic
2023-12-12 17:49:40 +08:00
前端在研发链条末端，往往话语权更低，毕竟一般概念上都是没有后端接口不行。
但链条反过来也不是不行，只要前端写的屎山够大，改不动了也能翻转驱动后端对接前端（狗头
xingdaorong
2023-12-12 17:55:02 +08:00
第一个问题前端和后端处理都是一样的，后端返回这种类型字符串，直接说没有语义化，数组就是数组，字符串是字符串，除非给一个特别理由，比如接口会慢几秒，其它不接受

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/999425

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX