咨询一下关于接口设计的问题

[Julio]

本人客户端开发，最近在新版开发过程中很痛苦，请教各位大佬。
我们团队关于接口的开发流程是：后端数据层建表，写数据层接口、后端应用层写 API 接口、客户端开发。
遇到的问题是：
1.客户端与后端应用层沟通的成本太大了，一个接口要沟通确定很多次（这一点可以通过规范 API 文档来解决）
2.客户端必须要等到接口给出来了，才能继续开发，很影响整体的效率。

为什么这个版本才觉得很痛苦？
主要是因为这个版本团队走了几个人，原先人多一些，感觉不是特别明显。

我觉得可以并行开发，就是先设计好 API 接口，然后后端和客户端都按照这个来同步进行开发，不是很好嘛，但是咨询了我们的后端，说不行。原因是，应用层不能自己写字段名，需要数据层给，数据层要等到表建好之后，才能确定字段名。
在我的了解应用层提供业务相关 API，不需要完全按照数据层给的字段和结构来返回接口吧？

所以想来问问，大家都是怎么处理的？应用层 API 返回的字段名称必须要和数据库里面的字段名一样吗？给我一些参考，谢谢啦！

[akira]

后端偷懒了。 或者框架绑的太死了

[Light3]

不是很懂 你管人数据库里叫什么名字呢..
还有就是你们后端开发真的懒..
我开发接口一般都是 和客户端沟通大概需要的字段 然后他们先写页面 然后谁这边先写完了 就做一个接口模拟数据 然后按照这个模拟数据的格式 返回 api 接口数据 并记录在本地 api 管理里面（有助于以后分锅） 然后写上每个字段的名字 类型 什么意思 不就 ok 了吗？（当然我们是小公司）

[Julio]

@akira 明白人
@Light3 对啊，这样不是很好嘛，哎。

[justinwu]

根据依赖倒置原则和稳定抽象原则，接口应该是抽象且稳定的，应用层和实现层都应依赖于接口，两边可以独立变化互不影响。

你们后端或是底层的人该转变下态度了，不然直接让客户端直接连数据库算了，自己也落得清闲。