这是一个创建于 953 天前的主题，其中的信息可能已经有所发展或是发生改变。
直接从数据库中取得模型，不需要的值就是一堆 null
如果是需要额外处理的字段，就在原本对象内放一个 params 的对象，再嵌套一层放处理的数据
能因为一个值需要转换一下数据而扯皮，哪怕是取模于 10 这种简易操作也要前端来做
 |
1
zilongzixue 2022-04-13 16:14:00 +08:00  1
null 值有什么问题，现在前端框架的表单不是自动处理 null 值的吗
|
 |
2
mokevip OP |
|
3
mokevip OP @zilongzixue 为什么要多出来这些数据呢？
|
 |
4
yedanten 2022-04-13 16:17:21 +08:00 via Android 3
单纯的偷懒行为，还有模型字段名和数据库字段名如果是完全一致，算是低危的信息泄露
|
 |
5
dicc 2022-04-13 16:17:23 +08:00
你知道我爬 Twitter 什么感受不，那字段。。。
|
 |
6
putaozhenhaochi 2022-04-13 16:18:24 +08:00 via Android
让后端加个 entity 转成 VO
|
 |
7
6IbA2bj5ip3tK49j 2022-04-13 16:23:27 +08:00 3
后端又懒又菜。
懒是因为用了一个巨大的万能对象应对所有接口。 菜是让人发现这么做了。 |
 |
8
arthas2234 2022-04-13 16:32:04 +08:00
null 值是可以加个配置过滤掉的，直接返回数据库字段肯定不可行
很好奇，用户表也是这么做的吗，我看第二张图里面还有 oldPassword 这个字段，也是厉害 |
 |
9
cweijan 2022-04-13 16:33:00 +08:00 1
其实就是偷懒, 后端懒得建个 DTO, 直接返回数据库实体.
|
 |
10
learningman 2022-04-13 16:38:36 +08:00 3
入侵最喜欢这种了，sql 注入的时候猜表累死人
|
|
11
mokevip OP emmm ，我因为这个问题和他们怼过无数次，我是给不了啥建议了，暂时救不了他们
|
|
13
mokevip OP @putaozhenhaochi 有没有文章这种，因为我是前端，对这个不太了解，后端是 JAVA 的
|
|
14
mokevip OP @arthas2234 所有的都是 = =
|
 |
15
lmmlwen 2022-04-13 16:45:08 +08:00 1
没时间啊，这就是最重要的，而且返回的数据结构这种东西对个人来说并无任何实际价值。我看有人说菜，这和菜没什么关系，谁不知道处理返回的资源，核心原因就是不是自己的东西不心疼
|
 |
16
clf 2022-04-13 16:53:28 +08:00
|
 |
17
47d7tEUBp521E8fJ 2022-04-13 16:53:47 +08:00
既然你都说了，以后出问题都是他们的锅。他们还是不做你就直接不用管即可，你把你分内的事情做好，早点把活做完摸鱼学习不香吗。
|
 |
18
cheng6563 2022-04-13 16:54:03 +08:00
又不是不能用。
后台的框架模板或者代码生成器就是这么返回的呗，所以说你不喜欢就单独开个接口。 既然都用快速开发框架了，肯定以开发速度为重，这种低危漏洞也无所谓了。 |
 |
19
spicecch 2022-04-13 17:02:36 +08:00
你可以先开发，然后自己写好接口文档并定义字段，让后端来接
|
 |
20
iamqiwei 2022-04-13 17:05:28 +08:00
是不是用了若依的框架，这个框架本身就这样，我公司也是这样
|
 |
21
golangLover 2022-04-13 17:07:01 +08:00 via Android 1
垃圾后端呗，还有什么原因
|
 |
22
DinnyXu 2022-04-13 17:10:57 +08:00 1
后端返回这种有很多 null 值的字段是因为后端在查询的时候调用的是一个通用方法，这个通用方法对应的就是表结构的字段，也就是 domain 。如果你需要只返回一些有数据的字段，后端需要将 domain 转换为 VO ，或者是直接写 SQL 查询映射 VO 。这种返回很多 null 纯粹是涂方便，也不算是懒，只能算不规范.....
|
 |
25
pelloz 2022-04-13 17:16:26 +08:00
这种情况一般出现在后端不知道前端需要什么字段，只知道前端需要这个业务内的字段。总的来说就是没人设计 api ，靠猜进行开发。
|
 |
27
westoy 2022-04-13 17:27:18 +08:00
不涉及安全(比如泄漏密码啊， 或者返回跨权限的字段)问题其实没什么毛病， 对 CDN 和后端缓存都挺友好的
|
 |
28
rabbbit 2022-04-13 17:28:28 +08:00
别纠结这个，如果领导没说就别管，出事了也跟你没关系。
对前端没影响，而且以后缺了啥字段也好取。 到时候得罪了后端，布尔值全给你返回来 1 0 。 |
 |
30
zzc032003 2022-04-13 17:45:26 +08:00
@putaozhenhaochi
为什么必须要转化啊？ 如果仅仅是把字段名改名，意义何在哪？ |
 |
31
Bingchunmoli 2022-04-13 17:47:45 +08:00 via Android
第一如果接口不是面向业务开发而是面向数据开发，针对数据做返回是没问题的，如果针对业务就考虑前端处理和后端处理的优缺点，前端处理是大部分情况吧因为无所谓安全，只是展示，但是后端性能有点影响，前段在用户侧用前端可以节省一些后段性能
|
|
32
Bingchunmoli 2022-04-13 17:48:52 +08:00 via Android 1
@iamqiwei ruoyi 是生成，如果你需要业务处理也可以写啊，面向数据的借口又不知道你业务需要忽略
|
|
33
Bingchunmoli 2022-04-13 17:49:22 +08:00 via Android
@clf 但是有的接口需要呢
|
|
34
Bingchunmoli 2022-04-13 17:50:29 +08:00 via Android
@xgfan 小公司这样很普遍，因为你做 vo 又不增加工资，卖出去就不管了，写代码时间多学习准备跳槽挺好的
|
 |
35
akira 2022-04-13 17:52:23 +08:00
你这是生怕别人不好脱裤么。。这下好了，直接 api 就能获取到数据了，渗透都不用了
|
 |
36
lecher 2022-04-13 17:55:25 +08:00
缺一个 BFF 框架，展示数据不能受限于后端开发人员的约束。
https://maguangguang.xyz/backend-for-frontend https://maguangguang.xyz/bff-governance 看看之前 v 站用户的分享 |
 |
37
gogogo1203 2022-04-13 17:57:40 +08:00
golang 的解决方案是 应用层 和 数据层 的 user 写成两个 struct, 进出应用层用 user, 数据层出来要强制转化格式 。
刚开始挺麻烦的， 做习惯了就好了 ``` package user type User struct { ID string `json:"id,omitempty"` Username string `json:"username"` Email string `json:"email"` Roles []string `json:"roles,omitempty"` PasswordHash []byte `json:"-"` } package db type User struct { ID string `db:"user_id"` Username string `db:"username"` Email string `db:"email"` Roles pq.StringArray `db:"roles"` PasswordHash []byte `db:"password_hash"` .... } ``` |
 |
38
TUNGH 2022-04-13 17:57:52 +08:00
作为后端开发,给前端的每一个接口几乎都重写了 VO,你们后端这样写,不但懒,而且蠢.
|
 |
39
jhdxr 2022-04-13 18:00:31 +08:00
如果本身接口就是简单的 CRUD ，为啥我觉得除了潜在的安全风险（敏感字段，例如密码之类的。但这也只要配置一个黑名单）以外这么做没啥问题？除了浪费了一点流量。上面还有人提字段名泄露啥的，改个名掩耳盗铃吗？又是真有一个注入点，想要拖数据的还需要在乎你有没有泄露字段？现在都是自动化工具了。
|
 |
40
446ENzu91KZ73A33 2022-04-13 18:00:59 +08:00
@akira api 本来不就是获取数据的吗？这个应该要怎么改？
|
 |
41
darkengine 2022-04-13 18:02:47 +08:00
@rabbbit 0 和 1 还算好的，以前接过一个屎山，后端返回来的布尔值是 1 和 2 。。。。。。。
|
 |
43
Qseven 2022-04-13 18:04:23 +08:00
对这种一个实体从底贯穿到外的做法，十分鄙视，写什么代码，麻烦回去种田。
|
 |
44
seakingii 2022-04-13 18:05:50 +08:00
建 VO 是好习惯
不过为了能早点下班的话懒点也能理解... |
 |
45
yyf1234 2022-04-13 18:23:05 +08:00 via iPhone 2
艸，以为看到我公司的代码了
|
 |
46
labulaka521 2022-04-13 18:43:00 +08:00
@yyf1234 +1
|
|
47
labulaka521 2022-04-13 18:43:50 +08:00
@darkengine 哈哈 我们用的 grpc + golang 布尔值在 proto 里就是定义成 1 或 2
|
 |
48
Dragonphy 2022-04-13 19:04:36 +08:00
我竟然觉得没什么问题[假笑]，不想要无关字段可以针对不同的需求建立 VO ，而且前端取模也没啥大不了的吧，我们的后端我让直接写 SQL[二哈]
|
 |
49
sampeng 2022-04-13 19:23:57 +08:00 1
这种后端写什么程序，回家种田吧。
先不说偷懒不偷懒，不摸鱼的员工不是好员工。 单说反正机器流量钱不是他出，按 LZ 的这个例子，最少流量费用要多出 50%出来。服务端 GZIP 需要 cpu 。cpu 利用率多出 50%。客户端需要解压缩，需要 get body ，客户端也是要损失一部分损耗在里面。 你们后端 leader 是吃屎的？这都不管？那管啥？ |
 |
52
ccppgo 2022-04-13 20:24:18 +08:00
既然是 java 。。属性为 null 这种东西用 jackson 处理一下不就好了么
|
 |
53
asfas1246 2022-04-13 20:57:17 +08:00
我一个接口，返回了 45 万个字符。其中需要的，10%都不到。
|
 |
54
aliveyang 2022-04-13 21:02:48 +08:00
什么阶段干什么事，不怎么重要的项目套模板没什么不好的
|
 |
56
XCFOX 2022-04-13 21:15:28 +08:00
这时候就体现出 GraphQL 的好处了，后端还是直接抛从数据库里取出来的对象，前端需要什么按需取就行了
|
 |
57
PopRain 2022-04-13 21:54:12 +08:00
楼上说的一个对象用到底就鄙视不能认同， 大部分企业应用有复杂的逻辑和界面，每个界面（前端）对应一个 VO ， 那管理起来太复杂了。。。。
|
 |
58
unnamedhao 2022-04-13 22:17:16 +08:00
前后端接口规则咋定，一般看谁能打过谁
|
 |
59
morize 2022-04-13 22:30:47 +08:00
作为前端，我觉得返回 null 没什么问题，做数据防御是基本的好吧。可选链 ?. 又不麻烦。
多余的字段怎么说呢，难道来需求了前端后端一起改吗，太麻烦了吧。 觉得不好自己再 format 一次咯，要是你习惯把接口的数据直接抛到 view 层当我没说。 |
 |
60
lanlanye 2022-04-13 22:36:56 +08:00
暴露了表结构可能是一个问题，另外如果冗余数据的内容非常多导致传输受到影响也不好。
除此之外其实没什么太大的问题，而且我个人的看法是少量的计算和格式转换交给前端做更好，毕竟前端的计算压力分散在每一个客户端（浏览器）上，而后端处理则是一台服务器处理所有请求需要的数据，显然前端处理可以分散压力。 当然实际项目中大部分人这么做是因为懒（摊手 |
 |
61
aababc 2022-04-13 22:44:43 +08:00
@labulaka521 卧槽，这么高级的吗？感觉这样会被人打死的！
|
 |
62
KHfqLAYYS6BKJT3R 2022-04-13 22:50:26 +08:00 2
楼上那么多说暴漏表结构的，专门起个跟数据库里表字段不一致的 VO ？
|
 |
63
lower 2022-04-13 23:07:18 +08:00 3
你实在看不起跟你协作的后端同事的话，就找他的 leader 或者老板来协调，在论坛来吐槽大可不必；
聊天记录里对方也说了，你不方便处理他再给你写个接口……有什么毛病么？ 大家都是吃这碗饭的，想挑毛病怎么都能挑几条； 前后端分离的模式本身就会引入一些新的问题，不可能有完美的方案能解决所有可能的隐患； 工作中我最害怕的就是遇上那种事儿特别多，总是坚持自己想法的同事或者领导，口一张就要让别人怎么怎么配合他工作，理由也是一大堆，每次都非要争赢，完全不管别人的情况…… 😔 |
|
64
labulaka521 2022-04-13 23:52:09 +08:00 via iPhone
@aababc 因为 golang 里的默认值问题只能这么搞了 目前还没被打 因为不是我设计的😆
|
 |
65
marcojbk 2022-04-14 07:46:20 +08:00 via iPhone 1
那我说个相反的，我司前端从来不处理任何数据，全都靠后端我给他处理好，他只负责展示。
|
 |
66
FawkesV 2022-04-14 08:43:10 +08:00
就是偷懒而已. 正常来写要写 vo 类映射的.
|
 |
67
changdy 2022-04-14 08:44:09 +08:00
哈哈哈 ..前后端 势如水火
你说后端菜 ,后端说你娱乐圈 .. 你说后端 null 全字段 ,后端说你 不会用 GraphQL ... 老老实实搬砖吧... 不要把公司的压迫 转移成了 前后端的撕逼 .... |
 |
68
masterclock 2022-04-14 09:06:37 +08:00 1
null 是 null ，不存在是不存在，是什么就返回什么
取模 10 这种操作让后端做？？你要取模 10 ，另一个前端要取模 11 ，怎么处理？ |
 |
69
zarvin 2022-04-14 09:07:47 +08:00
无解，后端不做，肯定就是前端做，工作量转移而已
|
 |
70
Felldeadbird 2022-04-14 09:20:41 +08:00 1
后端来说一下，这种低风险的字段映射一般情况可以忽略安全考量。全字段输出更加省事。后端不知道前端要什么数据啊。没有明确规范下，非敏感库全字段输出节省了前端沟通成本。
就算你做了字段处理，人总会犯错的。如果觉得敏感应该找后端和负责人来处理。 |
 |
71
wolfie 2022-04-14 09:35:22 +08:00
OP 就是平时接触到的高血压前端
|
 |
72
itechnology 2022-04-14 09:52:22 +08:00 1
作为一个后端，我觉得他们这样做完全没问题，无非就是有点不规范而已。
|
 |
73
wonderfulcxm 2022-04-14 09:58:58 +08:00 via iPhone
laravel Eloquent ORM 可以很方便设置隐藏、显示哪些字段。
|
 |
74
Vitta 2022-04-14 10:07:54 +08:00 1
《用你写的接口我都不如直接用云数据库》
|
 |
75
knightdf 2022-04-14 10:11:05 +08:00
返回给前端的到底是 VO 还是 DTO ？怎么看楼上两种叫法都有？
|
 |
76
v2orz 2022-04-14 10:12:01 +08:00
不好说对错，这种事，关系好的商量一下就好，早点搞完早点跟前端兄弟吃火锅去
不是所有系统都要考虑什么多传几个字符、gzip 压缩这些的，具体场景具体分析 人家就要快，就要便宜，给你 DeadLine ，只能提前不能推迟 不过我也遇到过，字段为 1 ，显示成第 1 行，都要后端给他转换好的人 |
 |
77
RealJacob 2022-04-14 10:20:23 +08:00
有时候多带一些数据是正常的，但是该处理的数据还是要处理好就可以了。别就查个表什么都不处理
|
 |
78
p1gd0g 2022-04-14 10:21:08 +08:00
我做全栈的时间就爱这么干，省事，还能给服务器减压
|
 |
79
keepeye 2022-04-14 10:21:52 +08:00
哈哈 搞前端的火气这么大吗？来哥请你去大保健消消火，298 套餐怎么样
|
 |
80
l00t 2022-04-14 10:31:42 +08:00
无非是懒了点，又不是不能用…… 你要说这是不是一个好的设计，那肯定不是。但也不算什么大事，写程序还是要提高自己的适应性，你总会遇到各种烂代码烂接口烂项目的。
|
 |
81
yor1g 2022-04-14 10:32:38 +08:00
有没有接口文档 , 有就他不对, 没有的话没啥问题. 后端都想直接给你一个方法, 自己写 sql 好了, 想要啥字段自己查
|
 |
83
zealinux 2022-04-14 10:45:28 +08:00 1
建议用 GraphQL
|
 |
84
lscexpress 2022-04-14 10:49:05 +08:00
@asfas1246 啥接口啊？吹牛有点过了吧
|
 |
86
daimubai 2022-04-14 11:23:37 +08:00
他喜欢你
|
 |
87
HeHeDaGe 2022-04-14 11:26:21 +08:00
yml 配置行就行了
jackson: default-property-inclusion: non_null |
|
88
akira 2022-04-14 11:33:20 +08:00
@mu666 不一样的，应该尽量只返回客户端需要展示的数据，遵循最小化原则。 同时数据里面的各种 id 应该尽量不可枚举， 特别是规律性的自增 id 等，均不应该返回给前端，不然非常容易出现平权漏洞。另外各种敏感数据以及隐私数据就更加要小心了，国内的话还好，没啥人较真，国外爆一个漏洞，公司直接可以关门了。
最后，这个后端看起来似乎是直接 select * ，然后就全部返回了，这种技术债迟早要还的。 |
 |
89
keeguai 2022-04-14 11:38:09 +08:00
交给前端做也能说得通，毕竟后端更多考虑通用性，给你这个功能取模 10 了，其他功能调用要不要去掉？
另外这种计算处理最好还是交给前端，前端计算压力是客户浏览器的，放在后端，就是公司服务器承担了。 至于返回 null 值，后端可以过滤，甚至可以自动过滤，JSON 转一下就没了，但是有时候 null 值也是有意义的。 你这个问题是你们公司前后端协同问题，是接口协议谁来定？是前后端谁来决定业务逻辑的问题。 跟技术没关系，是个管理问题。 |
 |
90
libook 2022-04-14 12:15:20 +08:00
都是管理上的问题，前后端应该在工作内容方面有个清晰的界限。
|
 |
91
potatowish 2022-04-14 12:26:54 +08:00 via iPhone
个人项目倾向于只返回需要的字段。公司项目那就另说了，只要管理没严格要求，那就怎么方便怎么来，毕竟工期在那摆着呢。你在和后端为了这些字段该不该一起返回争的面红耳赤的时候，隔壁组的兄弟已经下班了～
|
 |
92
falcon05 2022-04-14 13:04:02 +08:00
那肯定不对的啊，请求某个用户信息接口，把密码也暴露出来怎么行。
|
 |
93
ZSeptember 2022-04-14 13:14:26 +08:00
看风格，RESTful 风格的 API 关注的是业务模型，返回的都是模型所有字段，而不是根据前端需要返回字段。
当然，你们现在的风格就是 RPC 风格，后端应该只返回前端需要的字段就可以了 |
 |
94
vyronlee 2022-04-14 13:17:20 +08:00 via iPhone
经典语句来了，”又不是不能用”。API 设计者不从使用方考虑便利性，而从自身实现来决定 API 长啥样，这种 API 就是不及格的。
|
|
95
Bingchunmoli 2022-04-14 13:54:55 +08:00
@akira 我们主键 ID 是过滤的其他以为都是业务需要，所以也会返回，无非是这个接口与另一个接口的问题。
|
|
96
Bingchunmoli 2022-04-14 13:58:19 +08:00
前端计算之前也有人讨论过， 因为比如 app 要展示分，PC 展示元，那么后端是两个数据还是说我一个数据，前端处理好。 显而易见面向数据通用性更广，但是面向业务(通常都是面向业务开发)，两个字段更方便，前端不需要做适配
|
 |
97
liuidetmks 2022-04-14 14:02:19 +08:00
直接找老板谈,
"你这有这样的员工,我活没法干了, 我还是他,选一个吧" |
|
98
masterclock 2022-04-14 14:11:28 +08:00
第一天：App 显示 分，后端返回 100
第二天：App 显示 元，后端返回 1 于是未更新的 App 上全部都显示 1 分 |
|
99
jhdxr 2022-04-14 14:12:08 +08:00 2
@akira 理论上是这样，但是实操是另外一回事。你数据库表设计范式全遵守了？
平权漏洞和是否返回给前端没有关系，而是应该做好权限校验。指望通过不告诉别人来解决漏洞，就好比“自研”各种加密算法，指望通过算法的保密来保证安全性。 别总觉得国外的月亮圆，信用卡数据这么多公司泄露了，哪个关门了？ 另外举一个具体的例子，获取用户信息。一个常见的，也是许多人口中偷懒的例子是直接一个 select * （当然，过滤掉诸如密码之类的敏感字段）作为一个 API ，前端自己去选取需要的信息。另外一个是根据每一个业务场景分别去做一个 API 。当然，还有 graphql 这种解决方案。我并不认为第一种方案一定是不好的。 |
|
100
wolfie 2022-04-14 14:14:29 +08:00
这种后端建议直接开除，多反了几个 null 搞得前端直接宕机不会写代码了。
|
Select Language