API设计是否需要跟着界面走？
在这里实际指代的是 界面展示Model的组装是否在后端进行（给界面生成一个根据界面定制的API）？
是否在后端组装对应于两种设计
* 后端组合各种Service，拼接成展示的Model，客户端无需任何逻辑，无需筛选任何字段直接展示
* 客户端（APP/WEB）组合各种Service，自行拼接出所需的Model，其保有较多逻辑，这里又有两种设计
* Service使用Restful接口，会多传很多无用的数据
* Service使用GraphQL接口，能指定所需数据，减少传输
Pros and Cons
在后端进行
* Pros:
* 若有类似多个前端展示完全一致的场景，如 安卓端/IOS端 界面展示完全一致，则界面的Model由后端生成 避免重复写前端逻辑
* 接口对应特定场景，因此后台对界面有很强的控制能力，甚至于可以在不修改前端逻辑的情况下，修改某些业务需求，对APP等不允许动态发布的场景特别有用。
* Cons:
* 与界面强耦合，复用难度较高
* 几乎每出一个新界面都需要一个特定的API与其配合，后端开发工作量大
* 前端界面易变，由此可能导致出现很多为了兼容历史版本而保留的 作用很少但不能去掉的 代码/接口
在前端进行
* pros:
* 后端开发任务减少，客户端可直接拿较为稳定的Service层接口编码，后端无需介入，大幅提高双方开发效率
* cons:
* 如果使用传统的Restful接口，会增加传输数据量，增加网关消耗（GraphQL可化解），当体量变大，流量也成为瓶颈时，该方式有待考虑
* 暴露的接口增多，安全隐患提升
对比，综上，对于APP类接口在后端拼装好返回给前端会比较好，对于WEB类接口，个人认为直接使用Service层接口会比较好。因此这两种方案应该是一种并存的方案，分别作用于APP与WEB
为减轻流量/网关压力及减少安全隐患，Service的暴露可以用白名单进行，需要用到的白名单Service才暴露到外部
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于