后端开发完接口才给接口定义, 是常规操作吗?

[Chingim]

最近加入了一个 1000 多人的中型公司, 在做项目的过程中, 后端不愿意先协商接口定义, 坚持等他开发完后才给接口文档, 理由是先给接口文档, 实现的过程中难免有变动, 改动起来很麻烦.

而作为前端, 我的理由是, 产品需求文档以及设计稿已经具备的情况下, 先约定接口定义, 前后端可以并行开发, 提高效率.

几番交涉之后还是没有达成一致, 现在是他开发一个接口, 给一个接口的文档.

之前就职的小公司是开发前给接口定义, 所有人评审接口之后再开发的. 我觉得效率很高, 定义好的接口, 开发过程中的改动也只是简单的增减, 不会有很大的变化.

是公司规模造成的开发流程差异吗? 请朋友们说说

[lihongjie0209]

前端先写静态页
后端先设计表结构

然后就一个具体的功能点二者一同开发，这样后面的联调就比较简单了

[reus]

@lihongjie0209 我说的是前后端共同遵守的接口约定，参数是什么，返回是什么，先定下来，怎么实现是后面的事情。例如一个加法接口，参数就是加数和被加数，返回另一个数，文档就是参数叫什么名字，例如 A, B，怎么传，post josn 还是 query string 还是都支持，返回的是什么结构，等等。至于后端怎么实现加法，这个前端不需要关心。
如果你连要做的是加法而不是乘法，参数是两个而不是多个，都不能确定的话，那就是我说的“需求未明确”。

[Aprilming]

我们公司都是前端把静态页面写好，搞点假数据，后端负责后端开发以及前端的数据渲染。

[Godykc]

服务端进度领先前端一个迭代周期
前后端分离完全可以错开啊

[amwyyyy]

@frandy 我前公司就是这样，效率挺不错的

[reus]

@lihongjie0209 你把“表结构”换成“参数和返回”，写下来，就等于是给了文档了，前端就可以把字段写进代码了，表结构那是后端实现阶段的事情。

[lihongjie0209]

@reus 想多了， 你数据不按照页面的需求给， 前端不得骂死你？一个展示页面需要调用三个接口来组装数据？后端可以把接口设计的尽量通用，但是前端的复杂度就上升了。

WEB 层和页面耦合那是必然的，WEB 存在的意义就是展示页面。

我们要避免的是核心业务对象和展示层的耦合

[wweir]

没有任何技术难度的项目，咋搞都行，推荐做法是后端负责人写接口文档草案，前、后端、测试等所有相关部门审阅后人手一份，基于文档进行开发。

有（后端）技术挑战性的项目，后端现行，开发出大致解构后，前端再参与开发。前端初期更多应该是理解业务、简单画界面、设计交互（划重点）。

[lihongjie0209]

@reus 你要把所有的接口定下来， 那就意味着你要做出很多假设， 而且这些假设会有依赖关系， 一旦其中的一个假设改变， 那么会导致一组假设全部失效，那也就是说你的接口全需要改。

需求是确定的，但是开发员人对需求的理解是随着开发慢慢增加了， 你期望别人在项目开发前就理解全部的需求并且不产生任何误解，我能想到的也只有简单的 CURD 了

[a0000]

我们公司是需求确定好，后端先定义接口，客户端确认有没有什么问题，没有问题，后端造假数据，让客户端先用着。并行开发，10 几个人的小团队

[a0000]

我们不是所有的都列出来，按界面出接口，边写边出，理想状态是后端不影响客户端开发

[owt5008137]

一般来说我是会先给接口，再实现功能。不过不排除中间会调整的可能性。

[Chingim]

@frandy
@hantsy
swagger 暂时没见使用。这个可以慢慢推，不用 word 我已经知足。

@passerbytiny 产品和项目管理同意延长工期，所以就没再探讨了。


@Antihank 以前公司确实开心，swagger/postman/zepin/Invision/asana/circleci/quip 各种服务各种协作工具，可惜产品赚不到钱



@yxcoder 适配也是一种办法，但是不能推进接口的规范化

[reus]

@lihongjie0209 那这就是你们的架构的问题，你们还活在前后端耦合的蛮荒时代。一个页面调几次接口也算问题？

后端当然会组装数据，但这些数据是符合“模型”，而不是符合“页面”。例如时间字段，返回的就是时间戳，不是 YYYY-MM-DD 之类的具体格式，因为前端可能需要显示的是“ xxx 前”。关联的数据也可以通过复合的字段返回，尽量减少前端的组装工作。现在的前端复杂度本来就是上升的，早就不是单纯写 css + html + jquery 的时代了。有时接口数据不复合需求，需要组装一下，是常见的事情了。前后端耦合，整体来讲就是低效率的。根据页面分接口，那多个端的，你也另外做一套？

后端服务的对象不是单纯的“ web 层”，web 只是前端的一种。移动端你另外写接口？小程序你另外写接口？内部调用你另外写接口？人力不是这么浪费的。

[ala2008]

小公司，后台先出文档，前后端初步同意，进入开发。有修改或缺，及时补上。整个过程是保持沟通的

[reus]

@lihongjie0209 你以为 CRUD 简单？能把复杂的业务模型整理成纯粹的 CRUD 接口，给前端调用，这就是后端架构功力的体现。

要做“假设”，说明需求还没有厘清。厘清了，就不需要假设。整理需求直到接口显而易见，本来就是开发的正常过程。何况题主已经说了“产品需求文档以及设计稿已经具备”，设计稿都出来了，你还想怎么大改？产品设计可能改，这就是你不先整理接口的原因？

[yogogo]

我们是前端先画页面，后端同时写接口，前端画完页面，后端也差不多写好接口了，然后联调。

[AngryMagikarp]

@reus 接口完全不照顾页面，那么前端（尤其是移动端）用起来会很难受。比如一个页面有三张表的数据，可以使用三个接口，但那样前端就要考虑先调用哪个，先展示哪个，还是全部调完再展示。这个也跟 UI 设计有关系，UI 说要一个 loading 一起展示，还是三个 loading 分别展示？因此接口不可能不照顾页面设计，那样做的才是真正的坑货。

多个端写多种接口很正常，很多应用多端的需求本身就有区别，就算当前没有区别，以后也很可能会有区别，分开容易维护。我遇到两端用同一个接口的情况下，我也会提供两个 URL 给他们分别用，但内部实现是同一套代码，这样方便以后改。内部调用更是一定要另外写接口了，都说了是内部调用怎么可能和外部接口用同一个？

接口在正式上线前变更字段很正常，只是上线后不改。一旦上线，做的也一定是兼容的更改。

你说的那些接口约定其实前端自己也能定，为什么必须后端定？前端就没有看产品需求？显然不是的，归根到底是市面上 90%的前端都不具备这个能力，因此就强依赖于后端。时间多的话，完全可以让前后端都出一套接口方案，然后开个会统一一下。那样就没有任何问题了。接口是前端和后端通信的方式，并不是后端说了算的，把接口设计的责任完全推给后端也是推卸责任的行为。

就你说的那个时间戳格式问题，我遇到过多少个前端都希望后端替他们返回“ XX 前”格式的。现实中那种真正为技术考虑的人少之有少，大部分人都只是想减少自己的工作量。这点不分前后端。

我的观点是：做一个“差不多”的接口文档是没多大意义的，因为这个东西开完产品会议前后端脑子里都应该有。做一个“完备”的接口文档则要投入很大时间精力，（前端也要参加！）并不值得，如果你们公司并不在乎的话也可以搞，不过这是公司上层决定的事，没必要针对后端程序员。

[Chingim]

@AngryMagikarp 其实我也不排斥前端出接口, 但是很多后端的接口跟数据库是耦合的, 如果前端出具的接口跟数据库表结构 /字段命名 /字段类型相去甚远, 那后端能接受吗?

我是赞成前端参与接口建设的, 但是如果没有开发前的接口讨论, 那么很难说什么接口建设.

[ety001]

@reus 把锅都推给需求不明确，的确是个好方法。。。