如何看待后端接口带出数据库全部字段

[mokevip]

直接从数据库中取得模型，不需要的值就是一堆 null

如果是需要额外处理的字段，就在原本对象内放一个 params 的对象，再嵌套一层放处理的数据

能因为一个值需要转换一下数据而扯皮，哪怕是取模于 10 这种简易操作也要前端来做

[zilongzixue]

null 值有什么问题，现在前端框架的表单不是自动处理 null 值的吗

[mokevip]

https://s1.ax1x.com/2022/04/13/LKT5eH.png

[mokevip]

@zilongzixue 为什么要多出来这些数据呢？

[yedanten]

单纯的偷懒行为，还有模型字段名和数据库字段名如果是完全一致，算是低危的信息泄露

[dicc]

你知道我爬 Twitter 什么感受不，那字段。。。

[putaozhenhaochi]

让后端加个 entity 转成 VO

[xgfan]

后端又懒又菜。
懒是因为用了一个巨大的万能对象应对所有接口。
菜是让人发现这么做了。

[arthas2234]

null 值是可以加个配置过滤掉的，直接返回数据库字段肯定不可行
很好奇，用户表也是这么做的吗，我看第二张图里面还有 oldPassword 这个字段，也是厉害

[cweijan]

其实就是偷懒, 后端懒得建个 DTO, 直接返回数据库实体.

[learningman]

入侵最喜欢这种了，sql 注入的时候猜表累死人

[mokevip]

emmm ，我因为这个问题和他们怼过无数次，我是给不了啥建议了，暂时救不了他们

[mokevip]

@dicc 啥感受

[mokevip]

@putaozhenhaochi 有没有文章这种，因为我是前端，对这个不太了解，后端是 JAVA 的

[mokevip]

@arthas2234 所有的都是 = =

[lmmlwen]

没时间啊，这就是最重要的，而且返回的数据结构这种东西对个人来说并无任何实际价值。我看有人说菜，这和菜没什么关系，谁不知道处理返回的资源，核心原因就是不是自己的东西不心疼

[clf]

就是没写 VO 的问题。

实在偷懒其实可以在类上加上 @JsonIgnore 这种注解就可以了。

[xujinhui1]

既然你都说了，以后出问题都是他们的锅。他们还是不做你就直接不用管即可，你把你分内的事情做好，早点把活做完摸鱼学习不香吗。

[cheng6563]

又不是不能用。
后台的框架模板或者代码生成器就是这么返回的呗，所以说你不喜欢就单独开个接口。
既然都用快速开发框架了，肯定以开发速度为重，这种低危漏洞也无所谓了。

[spicecch]

你可以先开发，然后自己写好接口文档并定义字段，让后端来接

[iamqiwei]

是不是用了若依的框架，这个框架本身就这样，我公司也是这样

[golangLover]

垃圾后端呗，还有什么原因

[DinnyXu]

后端返回这种有很多 null 值的字段是因为后端在查询的时候调用的是一个通用方法，这个通用方法对应的就是表结构的字段，也就是 domain 。如果你需要只返回一些有数据的字段，后端需要将 domain 转换为 VO ，或者是直接写 SQL 查询映射 VO 。这种返回很多 null 纯粹是涂方便，也不算是懒，只能算不规范.....

[mokevip]

@xujinhui1 小公司，我算是前端的管理，还是不能完全摸鱼不管的。。

[mokevip]

@iamqiwei 卧槽，一样！

[pelloz]

这种情况一般出现在后端不知道前端需要什么字段，只知道前端需要这个业务内的字段。总的来说就是没人设计 api ，靠猜进行开发。

[mokevip]

@spicecch 那后端炸了哈哈

[westoy]

不涉及安全(比如泄漏密码啊， 或者返回跨权限的字段)问题其实没什么毛病， 对 CDN 和后端缓存都挺友好的

[rabbbit]

别纠结这个，如果领导没说就别管，出事了也跟你没关系。
对前端没影响，而且以后缺了啥字段也好取。
到时候得罪了后端，布尔值全给你返回来 1 0 。

[R18]

@yedanten
想请教一下，数据库列名不也是语义化的吗。难不成返回前端的时候要另改一个名字。

[zzc032003]

@putaozhenhaochi
为什么必须要转化啊？ 如果仅仅是把字段名改名，意义何在哪？

[Bingchunmoli]

第一如果接口不是面向业务开发而是面向数据开发，针对数据做返回是没问题的，如果针对业务就考虑前端处理和后端处理的优缺点，前端处理是大部分情况吧因为无所谓安全，只是展示，但是后端性能有点影响，前段在用户侧用前端可以节省一些后段性能

[Bingchunmoli]

@iamqiwei ruoyi 是生成，如果你需要业务处理也可以写啊，面向数据的借口又不知道你业务需要忽略

[Bingchunmoli]

@clf 但是有的接口需要呢

[Bingchunmoli]

@xgfan 小公司这样很普遍，因为你做 vo 又不增加工资，卖出去就不管了，写代码时间多学习准备跳槽挺好的

[akira]

你这是生怕别人不好脱裤么。。这下好了，直接 api 就能获取到数据了，渗透都不用了

[lecher]

缺一个 BFF 框架，展示数据不能受限于后端开发人员的约束。
https://maguangguang.xyz/backend-for-frontend
https://maguangguang.xyz/bff-governance

看看之前 v 站用户的分享

[gogogo1203]

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"`
....
}

```

[TUNGH]

作为后端开发,给前端的每一个接口几乎都重写了 VO,你们后端这样写,不但懒,而且蠢.

[jhdxr]

如果本身接口就是简单的 CRUD ，为啥我觉得除了潜在的安全风险（敏感字段，例如密码之类的。但这也只要配置一个黑名单）以外这么做没啥问题？除了浪费了一点流量。上面还有人提字段名泄露啥的，改个名掩耳盗铃吗？又是真有一个注入点，想要拖数据的还需要在乎你有没有泄露字段？现在都是自动化工具了。

[mu666]

@akira api 本来不就是获取数据的吗？这个应该要怎么改？

[darkengine]

@rabbbit 0 和 1 还算好的，以前接过一个屎山，后端返回来的布尔值是 1 和 2 。。。。。。。

[jorneyr]

@yedanten 你这是想给数据库字段加密么。

[Qseven]

对这种一个实体从底贯穿到外的做法，十分鄙视，写什么代码，麻烦回去种田。

[seakingii]

建 VO 是好习惯

不过为了能早点下班的话懒点也能理解...

[yyf1234]

艸，以为看到我公司的代码了

[labulaka521]

@yyf1234 +1

[labulaka521]

@darkengine 哈哈 我们用的 grpc + golang 布尔值在 proto 里就是定义成 1 或 2

[Dragonphy]

我竟然觉得没什么问题[假笑]，不想要无关字段可以针对不同的需求建立 VO ，而且前端取模也没啥大不了的吧，我们的后端我让直接写 SQL[二哈]

[sampeng]

这种后端写什么程序，回家种田吧。

先不说偷懒不偷懒，不摸鱼的员工不是好员工。

单说反正机器流量钱不是他出，按 LZ 的这个例子，最少流量费用要多出 50%出来。服务端 GZIP 需要 cpu 。cpu 利用率多出 50%。客户端需要解压缩，需要 get body ，客户端也是要损失一部分损耗在里面。

你们后端 leader 是吃屎的？这都不管？那管啥？

[rabbbit]

@sampeng
息怒，这都不算啥，你还没见过批量删除让前端自己写循环发请求挨个删的。

[dengshen]

@TUNGH 做 node 不仅要重写 vo 还要重写 dto 日了狗了

[ccppgo]

既然是 java 。。属性为 null 这种东西用 jackson 处理一下不就好了么

[asfas1246]

我一个接口，返回了 45 万个字符。其中需要的，10%都不到。

[aliveyang]

什么阶段干什么事，不怎么重要的项目套模板没什么不好的

[Cielsky]

@mokevip 那你跟后端管理说不就完事了，然后保留聊天记录方便甩锅即可

[XCFOX]

这时候就体现出 GraphQL 的好处了，后端还是直接抛从数据库里取出来的对象，前端需要什么按需取就行了

[PopRain]

楼上说的一个对象用到底就鄙视不能认同， 大部分企业应用有复杂的逻辑和界面，每个界面（前端）对应一个 VO ， 那管理起来太复杂了。。。。

[unnamedhao]

前后端接口规则咋定，一般看谁能打过谁

[morize]

作为前端，我觉得返回 null 没什么问题，做数据防御是基本的好吧。可选链 ?. 又不麻烦。
多余的字段怎么说呢，难道来需求了前端后端一起改吗，太麻烦了吧。
觉得不好自己再 format 一次咯，要是你习惯把接口的数据直接抛到 view 层当我没说。

[lanlanye]

暴露了表结构可能是一个问题，另外如果冗余数据的内容非常多导致传输受到影响也不好。
除此之外其实没什么太大的问题，而且我个人的看法是少量的计算和格式转换交给前端做更好，毕竟前端的计算压力分散在每一个客户端（浏览器）上，而后端处理则是一台服务器处理所有请求需要的数据，显然前端处理可以分散压力。

当然实际项目中大部分人这么做是因为懒（摊手

[aababc]

@labulaka521 卧槽，这么高级的吗？感觉这样会被人打死的！

[cjzlol]

楼上那么多说暴漏表结构的，专门起个跟数据库里表字段不一致的 VO ？

[lower]

你实在看不起跟你协作的后端同事的话，就找他的 leader 或者老板来协调，在论坛来吐槽大可不必；
聊天记录里对方也说了，你不方便处理他再给你写个接口……有什么毛病么？

大家都是吃这碗饭的，想挑毛病怎么都能挑几条；
前后端分离的模式本身就会引入一些新的问题，不可能有完美的方案能解决所有可能的隐患；

工作中我最害怕的就是遇上那种事儿特别多，总是坚持自己想法的同事或者领导，口一张就要让别人怎么怎么配合他工作，理由也是一大堆，每次都非要争赢，完全不管别人的情况……
😔

[labulaka521]

@aababc 因为 golang 里的默认值问题只能这么搞了 目前还没被打 因为不是我设计的😆

[marcojbk]

那我说个相反的，我司前端从来不处理任何数据，全都靠后端我给他处理好，他只负责展示。

[FawkesV]

就是偷懒而已. 正常来写要写 vo 类映射的.

[changdy]

哈哈哈 ..前后端 势如水火
你说后端菜 ,后端说你娱乐圈 ..
你说后端 null 全字段 ,后端说你 不会用 GraphQL ...

老老实实搬砖吧... 不要把公司的压迫 转移成了 前后端的撕逼 ....

[masterclock]

null 是 null ，不存在是不存在，是什么就返回什么

取模 10 这种操作让后端做？？你要取模 10 ，另一个前端要取模 11 ，怎么处理？

[zarvin]

无解，后端不做，肯定就是前端做，工作量转移而已

[Felldeadbird]

后端来说一下，这种低风险的字段映射一般情况可以忽略安全考量。全字段输出更加省事。后端不知道前端要什么数据啊。没有明确规范下，非敏感库全字段输出节省了前端沟通成本。

就算你做了字段处理，人总会犯错的。如果觉得敏感应该找后端和负责人来处理。

[wolfie]

OP 就是平时接触到的高血压前端

[itechnology]

作为一个后端，我觉得他们这样做完全没问题，无非就是有点不规范而已。

[wonderfulcxm]

laravel Eloquent ORM 可以很方便设置隐藏、显示哪些字段。

[Vitta]

《用你写的接口我都不如直接用云数据库》

[knightdf]

返回给前端的到底是 VO 还是 DTO ？怎么看楼上两种叫法都有？

[v2orz]

不好说对错，这种事，关系好的商量一下就好，早点搞完早点跟前端兄弟吃火锅去
不是所有系统都要考虑什么多传几个字符、gzip 压缩这些的，具体场景具体分析
人家就要快，就要便宜，给你 DeadLine ，只能提前不能推迟

不过我也遇到过，字段为 1 ，显示成第 1 行，都要后端给他转换好的人

[RealJacob]

有时候多带一些数据是正常的，但是该处理的数据还是要处理好就可以了。别就查个表什么都不处理

[p1gd0g]

我做全栈的时间就爱这么干，省事，还能给服务器减压

[keepeye]

哈哈 搞前端的火气这么大吗？来哥请你去大保健消消火，298 套餐怎么样

[l00t]

无非是懒了点，又不是不能用…… 你要说这是不是一个好的设计，那肯定不是。但也不算什么大事，写程序还是要提高自己的适应性，你总会遇到各种烂代码烂接口烂项目的。

[yor1g]

有没有接口文档 , 有就他不对, 没有的话没啥问题. 后端都想直接给你一个方法, 自己写 sql 好了, 想要啥字段自己查

[l00t]

@sampeng 你要考虑这么极端那解释性语言可以都直接下岗了。HTTP 本身效率也不高，可以废了。

[zealinux]

建议用 GraphQL

[lscexpress]

@asfas1246 啥接口啊？吹牛有点过了吧

[sampeng]

@l00t 编程语言是合理的浪费，并不极端。。lz 这种情况是不合理的。。不能偷换概念

[daimubai]

他喜欢你

[HeHeDaGe]

yml 配置行就行了

jackson:
default-property-inclusion: non_null

[akira]

@mu666 不一样的，应该尽量只返回客户端需要展示的数据，遵循最小化原则。 同时数据里面的各种 id 应该尽量不可枚举， 特别是规律性的自增 id 等，均不应该返回给前端，不然非常容易出现平权漏洞。另外各种敏感数据以及隐私数据就更加要小心了，国内的话还好，没啥人较真，国外爆一个漏洞，公司直接可以关门了。

最后，这个后端看起来似乎是直接 select * ，然后就全部返回了，这种技术债迟早要还的。

[keeguai]

交给前端做也能说得通，毕竟后端更多考虑通用性，给你这个功能取模 10 了，其他功能调用要不要去掉？
另外这种计算处理最好还是交给前端，前端计算压力是客户浏览器的，放在后端，就是公司服务器承担了。
至于返回 null 值，后端可以过滤，甚至可以自动过滤，JSON 转一下就没了，但是有时候 null 值也是有意义的。
你这个问题是你们公司前后端协同问题，是接口协议谁来定？是前后端谁来决定业务逻辑的问题。
跟技术没关系，是个管理问题。

[libook]

都是管理上的问题，前后端应该在工作内容方面有个清晰的界限。

[potatowish]

个人项目倾向于只返回需要的字段。公司项目那就另说了，只要管理没严格要求，那就怎么方便怎么来，毕竟工期在那摆着呢。你在和后端为了这些字段该不该一起返回争的面红耳赤的时候，隔壁组的兄弟已经下班了～

[falcon05]

那肯定不对的啊，请求某个用户信息接口，把密码也暴露出来怎么行。

[ZSeptember]

看风格，RESTful 风格的 API 关注的是业务模型，返回的都是模型所有字段，而不是根据前端需要返回字段。
当然，你们现在的风格就是 RPC 风格，后端应该只返回前端需要的字段就可以了

[vyronlee]

经典语句来了，”又不是不能用”。API 设计者不从使用方考虑便利性，而从自身实现来决定 API 长啥样，这种 API 就是不及格的。

[Bingchunmoli]

@akira 我们主键 ID 是过滤的其他以为都是业务需要，所以也会返回，无非是这个接口与另一个接口的问题。

[Bingchunmoli]

前端计算之前也有人讨论过， 因为比如 app 要展示分，PC 展示元，那么后端是两个数据还是说我一个数据，前端处理好。 显而易见面向数据通用性更广，但是面向业务(通常都是面向业务开发)，两个字段更方便，前端不需要做适配

[liuidetmks]

直接找老板谈,
"你这有这样的员工,我活没法干了, 我还是他,选一个吧"

[masterclock]

第一天：App 显示 分，后端返回 100
第二天：App 显示 元，后端返回 1

于是未更新的 App 上全部都显示 1 分

[jhdxr]

@akira 理论上是这样，但是实操是另外一回事。你数据库表设计范式全遵守了？

平权漏洞和是否返回给前端没有关系，而是应该做好权限校验。指望通过不告诉别人来解决漏洞，就好比“自研”各种加密算法，指望通过算法的保密来保证安全性。

别总觉得国外的月亮圆，信用卡数据这么多公司泄露了，哪个关门了？

另外举一个具体的例子，获取用户信息。一个常见的，也是许多人口中偷懒的例子是直接一个 select * （当然，过滤掉诸如密码之类的敏感字段）作为一个 API ，前端自己去选取需要的信息。另外一个是根据每一个业务场景分别去做一个 API 。当然，还有 graphql 这种解决方案。我并不认为第一种方案一定是不好的。

[wolfie]

这种后端建议直接开除，多反了几个 null 搞得前端直接宕机不会写代码了。