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

[mokevip]

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

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

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

[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 搞得前端直接宕机不会写代码了。