这是一个创建于 2026 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近接了个需求，我后端写得比较急，方案设计得不太好，以为大功告成，然后就和前端对接了。
后面发现方案有问题，然后我就改了好几个接口，又找前端对接。。
再后来发现还是有问题，于是又改了接口。
我已经不太好意思跟他说我又改了接口了。
前后端怎么友好地对接口啊？
 |
1
cccy0 2019-06-12 23:12:18 +08:00  1
没什么好的解决方法， 接口文档可以也加入 git， 像 postman 那样导出的 json 格式的文件可以清晰地看出修改了什么地方
|
 |
2
TwoDogSon 2019-06-12 23:13:43 +08:00 9
带瓶可乐
|
 |
3
RingoTC 2019-06-12 23:21:57 +08:00
磨刀不误砍柴工吧，接口设计太草率了，之后肯定会花格外多的时间在修改上。还不如最开始好好设计接口。
|
 |
4
luckyrayyy 2019-06-12 23:23:28 +08:00
1、总结经验。2、设计上多留时间。3、选择合适的接口管理工具方便别人浏览和修改。
|
 |
5
oneisall8955 2019-06-12 23:24:43 +08:00 via Android
前后端分离了接口一般都是做的时候就定义好的，一般来说，根据需求，按模块划分，前端需要什么，定义好格式，后端就提供什么
|
 |
6
Sanko 2019-06-12 23:37:47 +08:00 via Android
我一般都是让前端整理他需要什么接口然后给我，我来实现
|
 |
7
chendy 2019-06-12 23:44:52 +08:00
一开始就和前端交流好，要啥接口，输入输出是啥，然后慢慢写慢慢接…
当然即使如此也可能会有小调整，无所谓，大方向没问题就好 |
 |
8
ChefIsAwesome 2019-06-12 23:46:47 +08:00 via Android
你先得知道你为什么要改。前端要求的理想情况是接口回的数据刚好够页面用。你这改了之后是让前端更好用呢，还是怎样。觉得不好意思就在你自己这里加 adapter，这样接口就不用变了。
|
 |
9
Vegetable 2019-06-12 23:52:48 +08:00 1
这问题不是怎么友好对接,而是怎么避免无意义的变更.
接口设计先于编码,所有可以设计的接口都设计完毕之后才可以开始写第一行代码,开始编码之前,前后端必须共同审核接口设计,双方同意之后开始开发 |
 |
10
weixiangzhe 2019-06-13 06:06:35 +08:00 via iPhone
@Sanko 比较困难啊 这边大部分前端不管业务 有些东西会很不合理🤣
|
|
11
Sanko 2019-06-13 06:56:43 +08:00 via Android
@weixiangzhe 我这项目很小，完全是 curd 前端给我他要显示的数据我帮他拿就 OK
|
 |
13
jowan 2019-06-13 08:01:12 +08:00 via iPhone 20
APIJSON 的老哥来了吗 没来我待会再回来看一下
|
 |
14
misaka19000 2019-06-13 08:31:31 +08:00 via Android
先梳理需求定义接口，定义好了再去实现
|
 |
15
kinghly 2019-06-13 08:37:22 +08:00 via Android
你自己业务都没整明白，肯定频繁改接口了。能力问题。
|
 |
16
redbuck 2019-06-13 08:49:22 +08:00
GraphQL
|
 |
17
gimp 2019-06-13 08:55:09 +08:00
我一般会问配合的前端需要什么接口，之后定下数据格式，再实现。
|
 |
18
poisedflw 2019-06-13 08:59:58 +08:00
让前端来定接口避免扯皮。
|
 |
19
maichael 2019-06-13 09:09:10 +08:00
看前端水平怎么样，如果水平跟你差不多，甚至比你还高的话，在设计阶段就要跟前端沟通，提前沟通能省很多时间。
|
 |
20
66beta 2019-06-13 09:09:29 +08:00 via Android
没想好就写，跟技术方案无关
|
 |
21
shawshi 2019-06-13 09:17:20 +08:00
别动约定参数啊
|
 |
23
xianxiaobo 2019-06-13 09:29:31 +08:00
@jowan 你是想笑死我吗？哈哈哈
|
 |
24
tt67wq 2019-06-13 09:34:00 +08:00 1
前端拿把椅子坐后端后面！物理对接才能逻辑对接！
|
 |
25
murmur 2019-06-13 09:37:16 +08:00
先看文档，然后真人 PK，谁赢了听谁的，友好是不可能有好的
|
 |
26
zhang77555 2019-06-13 09:59:00 +08:00
后端数据接口应该以稳定性可拓展性和效率为主,如果前端非要纠结接口细节,可以让他们自己加中台.
|
 |
28
hzb 2019-06-13 10:01:54 +08:00
共同的敌人不应该是 产品吗
|
 |
29
yiyi11 2019-06-13 10:08:04 +08:00
自己对啊，前后端架构分离，人员不分离。专职前端人员负责静态页面以及样式部分，后端人员负责写接口以及对接口，写 js，涉及请求接口的逻辑都由后端做。
|
 |
30
biossun 2019-06-13 12:42:59 +08:00
接口设计定好规范，接口数据只依据业务需求来定，不要耦合服务器端的具体实现。
|
 |
31
leopku 2019-06-13 13:02:49 +08:00
GraphQL +10086
|
 |
32
darknoll 2019-06-13 13:17:02 +08:00
前后端一个人包了
|
 |
33
waising 2019-06-13 14:30:19 +08:00
没有一顿烧烤解决不了的问题，有那就。。。。
|
 |
34
KuroNekoFan 2019-06-13 14:33:38 +08:00
前端最好还是自己抽象一层 viewmodel，而不是直接使用后端的数据结构，这样对大家都好
|
 |
35
index90 2019-06-13 14:59:20 +08:00
接入层服务，直接根据页面元素和 URL 定义肯定不会有问题。
如果后台想抽象一些固定的业务逻辑接口，在接入层服务下面搞多一层业务层服务，接入层服务和业务层之间的接口，自己爱怎么改怎么改。 多说一句，前端需求变更非常频繁，接入层接口不用考虑过多，不要引入太多技术思维。说不定你这个接口上线不到一个星期，需求就改了，接口的生命周期就结束了。 |
 |
36
Pilippa 2019-06-13 15:28:22 +08:00 via iPhone
g RPC
|
 |
37
ganbuliao 2019-06-13 16:07:53 +08:00
这边建议您晚上吃顿烧烤呢！不然前端有可能掏刀！！ ^_^
|
 |
38
drioou 2019-06-13 16:32:02 +08:00
不改字段名和数据结构 什么都好商量
|
 |
39
balabalaguguji 2019-06-13 16:40:53 +08:00
前后端一起商量下需要什么数据，然后在你开发完接口之前，你可以写一个 mock 给客户端用，后面发现有没考虑到的地方再进行完善修改接口，其实良好沟通是很重要的，建议你把接口都写一下接口文档，这样客户端看的清楚明白，你可以试下 https://easydoc.xy 专门写接口文档的，还可以在线测试你的接口是否 ok，然后可以一键生成接口文档，调用示例，还有 mock 配置。
|
|
41
balabalaguguji 2019-06-13 16:41:31 +08:00
|
 |
42
U2Fsd 2019-06-13 16:43:22 +08:00
自己写前端和后端
|
 |
44
zhuzhibin 2019-06-13 21:50:28 +08:00
自己全干 就完事
|
 |
45
zisway 2019-06-13 22:13:43 +08:00
开发前和前端一起接口评审，两边对过了接口，再开发会比较稳。即使后续要改接口，说明当时两边都没考虑好，那么也不用不好意思。
|
 |
46
V2exUser 2019-06-14 00:05:33 +08:00 via Android
我认为是你对需求理解不到位就开工了
|
 |
47
limuyan44 2019-06-14 02:12:24 +08:00 via Android
先评接口再开发呗 除非是什么野路子，都分离了需求也有了哪有那么多接口改动。
|
 |
48
haohappy 2019-06-14 10:01:46 +08:00
用 apijson 啊 直接淘汰后端
|
|
49
index90 2019-06-14 10:03:14 +08:00
|
 |
50
luvxy 2019-06-14 16:00:40 +08:00
我前端，一般先大概评估需求 先定制接口 商量好字段 后段照着我说的给数据
|
Select Language