关于 API 的设计，是一个 API 包含三个结构体还是每个 API 一个结构体呢？

[beneo]

我们的架构是前后端分离的，我是写 Java 的，要向 App、H5、PC 等提供接口；之前我们的业务比较简单，基本上一个页面一个 API，慢慢业务起来了，API 的返回结构体开始复杂，我们后端也开始做复用和抽象；

今天和 App 开发争论一个问题。App 上有个页面，里面分成三大块，每块都是一个 Excel 的结构体，而且每个 Excel 的结构体，在其他好几个页面上面，都有复用。某一个页面需要一个，另外一个页面需要另一个，这样的情况；

目前 App 那边一直坚持这个页面只要一个 API，一次返回三个结构体；原因是对用户体验友好。

而我做后端的觉得，这个 Excel 结构体复用的地方比较多，想做到单一职责，应该分三个 API 来调用；

我想问问大家怎么看这个问题，有没有比较正确的姿势来解

[xialdj]

你需要 graphql 前端爱用什么结构就用什么结构

[Ouyangan]

按照我的习惯 , 我会拆开 , 至于为什么... 一对比还真想不出什么理由.

[SmiteChow]

graphql 就是个坑， 远离

[qs]

之前想拆, 被前端拒绝了, 也就没做了。

[caixiexin]

不知道你们后端服务有没有拆分，有的话，就可以提供一个聚合接口，这个聚合接口的数据通过查询其他几个接口数据后组装而成。
类似微服务的概念。

[TommyLemon]

APIJSON 就是一个很好的解决方案啊，
自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果，
期间自动校验权限、结构、内容，自动防 SQL 注入。

通过自动化 API，前端可以定制任何数据、任何结构！
大部分 HTTP 请求后端再也不用写接口了，更不用写文档了！
前端再也不用和后端沟通接口或文档问题了！再也不会被文档各种错误坑了！
后端再也不用为了兼容旧接口写新版接口和文档了！再也不会被前端随时随地没完没了地烦了！

在线解析
自动生成文档，清晰可读永远最新
自动生成请求代码，支持 Android 和 iOS
自动生成 JavaBean 文件，一键下载
自动管理与测试接口用例，一键共享
自动校验与格式化 JSON，支持高亮和收展

对于前端
不用再向后端催接口、求文档
数据和结构完全定制，要啥有啥
看请求知结果，所求即所得
可一次获取任何数据、任何结构
能去除重复数据，节省流量提高速度

对于后端
提供通用接口，大部分 API 不用再写
自动生成文档，不用再编写和维护
自动校验权限、自动管理版本、自动防 SQL 注入
开放 API 无需划分版本，始终保持兼容
支持增删改查、模糊搜索、正则匹配、远程函数等

后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！
github.com/TommyLemon/APIJSON
创作不易，GitHub 右上角点 Star 支持下吧，谢谢^_^

[TommyLemon]

@SmiteChow
哈哈，看来你是用过了。
字段、状态码、权限控制、表关联查询... 确实一堆的坑。

提供自动化 API 的 APIJSON 才是简单高效的解决方案，看上面的回复。

APIJSON 对比 GraphQL：
完爆 Facebook/GraphQL，APIJSON 全方位对比解析
https://juejin.im/post/5ae80edd51882567277433cf

[TommyLemon]

@Numbcoder
有关联能并发发起？第二个接口要用第一个接口返回的数据作为参数，并发怎么搞？哪个接口先回调都不清楚