REST 接口让前端在请求中指定需要返回的字段是否合理?

• 資深大佬 : humpy

  那可以再去看看 graphql

• 資深大佬 : wunonglin

  后端不是有 control 和 service 吗，control 整合 service 的数据不就行了

• 資深大佬 : wysnylc

  字段不同就是结构不同,结构不同应当定义为不同接口

• 資深大佬 : yaphets666

  作为一个前端我是很烦这种.当然我知道有 GraphQL 这种东西. 我很好奇为什么接口不能分开呢? 通过 extends 和 Override 同时把以后可能同意修改的字段和各功能不同的字段区分开,可以解决这个问题吗?

• 資深大佬 : Sapp

  我不理解为什么要这么干，你直接多开几个接口，接口后续再按照你自己的逻辑分发不就行了吗？一个不同的业务需求开一个新的接口，这不是很正常的吗？为什么非要一个接口一把梭，另外接口返回的数据最好是固定的类型，不然前端没有 ts 加持很容易出问题。

• 資深大佬 : yaphets666

  我不懂 JAVA 啊,这是不是有 SQL 注入的风险?

• 資深大佬 : a398058068

  GraphQL

• 資深大佬 : love

  很合理的做法，在哪篇讲 rest 文章里我记得也是标准做法

• 資深大佬 : nekochyan

  很抗拒，基本都是不同结构就用不同接口

• 資深大佬 : misaka19000

  「会出现很多相同模型不一样的 api 」这是什么意思？

• 資深大佬 : beginor

  这个很合理吧，我们提供的的通用 API， 都是前端指定输出字段， 指定过滤条件。 服务端只要配置数据表就行了， 大家合作好开心

• 資深大佬 : beginor

  不服的话可以参考 GraphQL 以及 OData ， 还有 elastic

• 資深大佬 : Kobayashi

  GraphQL?

• 資深大佬 : shunia

  只能说适应了以后就挺香：
  1. 接口其实是变快了，因为相当于 batch，后台服务针对单个需求消耗的时间肯定是远小于创建 http 连接并等待返回的时间的；
  2. 后端接口会因此变得纯粹，更加弱业务化，很适合当前大前端 setState 这种风格的开发模式；
  3. 前端代码也会因此从设计上更加模块化，做好合理的数据拆解后，分别 dispatch 到不同的模块里很奈斯；

• 資深大佬 : xuanbg

  多几个接口不是坏事，永远不要试图把不同需求的接口合并成一个。

• 資深大佬 : jasl

  其实顺着这个思路协议没出大毛病的话。。。

  恭喜你重新发明了 https://jsonapi.org/ ！

• 資深大佬 : Gleven

  建议试试 graphql，完美解决主提出的问题

• 資深大佬 : goodboy95

  @yaphets666 sql 注入倒不用担心，可以在后端搞一个字段白名单，白名单之外的不给

• 資深大佬 : Elroooo0Y

  不同的场景让前端传不同的场景 id
  后台对不同的场景配置不同的查询数据策略

• 資深大佬 : aguesuka

  假如你的接口是一个函数，你的想法就是给这个函数加上一个泛型参数。如果对类型系统没有深刻的理解的话，业务的复杂程度越高，这个接口成为一坨的几率也越高。

  不过如果你是程序语言专家，自信可以精通自己写的 dsl，或者接口足够简单。完全可以放飞自我。