关于前后端接口联调的问题讨论

[zy0829]

技术经理提出了一个要求： 后端提前设计好 api 文档，前端按照文档 mock 开发，然后也不需要联调这个过程。

我在想这样真的就不需要联调了吗？往往身边的同事连个文档都不会看，让前后端按照文档开发真的可行吗？这样会不会更繁琐

[xiang0818]

没问题。我们已经这样子搞了 5 年了。
1 、后端开发定义好接口（接口定义网址： https://nei.netease.com ）直接给到前端
2 、前端查看接口，如果觉得有问题，直接给后端说，或者汇总后抽个时间两个人过一次接口，约定接口后端完成时间。
3 、接口确定完成后。前、后端并行开发，与此同时 QA 完成测试用例评审并提供冒烟用例。
4 、前后端完成冒烟用例能够正常执行，那么就提测。（这一步要说也是联调，只不过换个说法）
5 、前端负责提测演示，提测演示过程中记录提测问题（或者记录需要调整的部分细节）。
6 、提测问题修复完成，发布提测邮件到项目组成员。

[bojackhorseman]

怎么可能不需要联调了，只能说减少了联调的时间。

[Duanpei]

我是觉得根据规定好的接口格式， 各自开发是可行的
虽然可能还是需要花费不少精力去联调
接口足够简单/配合足够默契， 这种方式的确可以省事不少

[sarices]

@zy0829 #13 只能这样了，没有完美的方案

[estk]

swagger + 版本控制可以有效解决前后端扯皮

[lplk]

理论上可以做，我们这样做过，但会面临一些问题：
- 后端出文档前必须把所有业务逻辑的实现理个大概，才能给出 api 文档，这个挺需要时间的（业务简单的话还好）
- 后续后端大概也会改 api ，因为前期思考，大概率没有实际投入开发深入，这时某些需求可能会有更好的方案，然后可能会改 api 的数据结构，不过第一步做的好的话，改动应该不会太大，只是说存在这个风险。
- 接口会有很多相互依赖，比如最简单的一个业务，必须先创建数据，才能有展示数据。如果业务复杂了，mock 可能会有些麻烦

所以，个人来看，联调的时间还是需要的，只是提前有接口文档，联调的时间相对会短一些

[ZZ74]

这种需要一直有实际做开发 10 年左右的前后端，写好文档后，双方过一遍就好了。
国内的环境一般很少有这样匹配条件。这个年数的不是被淘汰了就是当领导去了

[moyechen]

我们使用 graphql ，每次也确实是先定义 schema 再写逻辑的，但是很多时候前端还是需要真实数据，联调是少不了的。

[treblex]

后端靠谱才行，我对接口就相当于给后端做一遍测试，除了 curd 没一个靠谱的接口🙉

[treblex]

@treblex curd 也有创建数据不验证，外建啥的，查数据的时候咔咔崩溃

[phieo2018]

这个理念是没问题的 就是比较看双方的水平

[OrionParker]

照着你技术经理的脸扇就行

[wanniwa]

没问题的，我们就是这样对接的，除非文档写的不行。
有的时候为了快，我们开发先写 web 层的接口，不写里面的实现逻辑，前端有个框架可以直接根据 swagger 导入生成接口，这样只要后端接口在代码中设计完了，前端就已经能对接了。mock 起来也很方便

[cmonkey]

后端先出 api 文档，前端基于 api 文档做开发，但是不连调是不行的.
从形而上来说, 实体无法直接面对变化，因为变化被视为不影响实体本质的外在现象
api 文档我们可以理解为一个实体

[lc5900]

开发过程就应该这样，但是肯定得有联调环节，不然肯定很多预期外的异常

[cc11]

我之前公司就是这样：
1.后端先设计开发文档和 api 文档，拉产品和前端开评审
2.后面等前端端开发完毕之后再联调
3.中间过程中也不可避免会不断修改文档，但是大体不会变

[lei2j]

肯定还是需要的

[pkoukk]

能减少联调时间和周期，但是不可能不联调
在没有接触到后端真实逻辑产生的数据之前，mock 的数据不太可能覆盖全部 corner case

[blackcellcode]

只能说缩短联调时间，不可能不联调

[karnaugh]

连文档都不看的话我觉得这程序员有点不合格吧，文档是一个约定，也是一个保证

前端的完整开发需要原型、设计图、接口三方面，既要等待设计图，又要等待接口

如果不提前出 api 文档，那说白了联调的时候前端是在开发，而后端在干啥呢，在修 bug

那么联调的时候后端把 bug 修完了，测试的时候干啥呢?

而前端在联调的时候实际是在开发，那最终这个联调阶段就有些奇怪了