直接从数据库中取得模型,不需要的值就是一堆 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 搞得前端直接宕机不会写代码了。
|