大家工作中的前后端是如何合作的？如何减少接口变更？

[crclz]

引言

首先我大量查阅了 V2EX 、知乎的讨论，发现前后端主流做的合作方法都是：

1. 前后端先商定一份接口文档（如果自动化一点，那么可以写一堆未实现的方法，然后用 swagger 生成文档）
2. 接着，前后端并行地开发，后端实现接口，前端依据接口文档进行开发
3. 前后端联调

问题

但是，在实践中，我发现了一些问题：

起草文档阶段往往是非常短暂的。在这个过程中，开发者无法了解系统全貌，自然无法确定完接口列表。随着前端和后端的开发工作的推进，这些忘记的接口、需要修改的接口才逐渐暴露，这会增加前后端合作、沟通的时间成本。

那么，在起草文档阶段，是否有一个系统的方法，来确保最小化这种需要增加、修改的接口数量？

[jinwyp]

很简单啊 找个资深前端定接口， 前端把界面开发完成 50%后 定的接口基本差不多了。

[Aprilming]

前端就给我画样式，接口啥的都是自己来写，自己对接，前端逻辑也是自己写。我的前端伙伴就是一个无情的 UI 机器人

[Airon]

交互能明确确认，确认完交互后端就能先出 mock，这样前后端开发就没啥影响。但是问题在于，需求是否真的明确这么细，产品是否完全不变动交互流程 (ps:很多傻逼产品明明自己确认的交互，开发出来还逼逼赖赖 技术们开发不考虑用户体验。。。然后又是改流程改接口)

[xuanbg]

起草文档阶段往往是非常短暂的，这个是有问题的。设计的必要时间还是要留的，好的设计能够有效减少写代码和测试的时间。所谓磨刀不误砍柴工。

[lenqu]

@ty89 干过 DBA 的都知道，数据库的一个普通权限读权限用户想拿到写权限需要找漏洞，反爬从来不在后端逻辑里写入不是么？

[Sapp]

你想要一次性拿全接口，如果是小项目开发有可能，只需要找个经验丰富的后端，他基本能 cover 你所有的需求，提供的接口一点不会少，妥妥的够你用，你想到的问题他都提前想到了，但是大项目基本不可能，一是你没办法招到那么多好后端，二是大项目本身就面临着需求变更，如果一开始就商量好所有的变更，我不说现实不现实，你们坐着开会都要开多久？开会的时间都可能比开发的时间长， 更何况真的能坐在会议桌就考虑到所有的问题？ 所以这方面就不要指望能完全搞定了。但是有另一个方法，可以减少接口变更带来的前后端成本，就是 typescript + 动态生成接口，前端不需要手写 ajax 请求，直接调用 node 根据后端文档生成好的请求方法，
例如：

const [getUsername, loading] = useRequest(getUsernameRequest)

useeffect(() => {
getUsername({userID: xxx})
}, [])
getUsernameRequest 直接生成的，同时生成了 interface 文件。
同时因为 typescript 的类型要求，前端也根本不需要看文档就能知道需要输入那些参数，并且你提到的后端改了接口，把 userID 改为了 userId，那么前端会直接收到 typescript 的报错提示，然后顺手改一下就行了。如果是改了接口名字，那么前端看一下 git 记录就知道你改了哪些名字，也不需要在口头沟通，或者等测试报错才知道你改了接口。
这样对于后端而言省了每天提醒前端我又改了什么什么的时间，对于前端省了每天要找后端对你又改了什么什么，怎么我测试的时候还没问题，测试一测就又出问题的时间，还少写了 interface 文件。

[6IbA2bj5ip3tK49j]

spring cloud contract 真的是垃圾，道理我都懂，用起来就是难用。
一个简单的
json array 为空列表 -> 合法
json array 不为空 -> 判断里面 item 字段
都做不到（只能通过很恶心的办法实现

[zqx]

需求评审-设计交互评审-前端和后端分别技术评审，然后再出接口文档，再开发，基本不会改了，除非产品需求变更了

[ty89]

@lenqu 你把数据库里的全部字段直接通过接口返回，那不就相当于直接复制你数据库表了吗，跟读写权限有啥关系。

[hejingyuan199]

我没有认真读前面的留言。不好意思。

我们的做法是，后端先把基础弄起来后。
前端给我们一个接口清单，我们去做。
毕竟前端跟客户最贴近。
不过如果遇到前端太胡闹的时候
就得吵吵架。

让前端提要求以后，
他们就不太 BB 地改需求了，
毕竟理亏在他们。

[sunxiansong]

与其避免接口变化不如拥抱变化，让变化可控、可测试、可追踪

- 首先会有一份 api 风格说明，说明一般的通用的数据结构风格、错误处理、token 机制
- 后端通过 cli 工具导出后端模型到前端的 ts 结构，前端可以拷贝或直接使用数据模型。导出的代码也包含了可能的错误码、常量枚举
- 后端直接写 ts http 调用的代码，并附上最小可测试代码（ jest 测试代码），在代码中标注文档（状态码、错误码等），这步其实主要是 route 标注，前端甚至可以直接复用 http 调用的代码
- 生成的 ts 数据结构和 http 调用代码放在 git 上，提交时填写恰当的注释标注 api 变更，这步主要是确保前端可以详细的跟踪 api 变动，前端可以 watch 文档工程追踪 api

- 时间充足的话，最好还是写足够的 api 集成测试


我以前还做过其他的尝试，在测试环境用 AOP 拦截请求，用 json schema 记录请求的 route/request body/response body,然后写到数据库里，再人工标注 api 注释，缺点就是首次请求之前不会有记录。