最近接了个需求,我后端写得比较急,方案设计得不太好,以为大功告成,然后就和前端对接了。
后面发现方案有问题,然后我就改了好几个接口,又找前端对接。。
再后来发现还是有问题,于是又改了接口。
我已经不太好意思跟他说我又改了接口了。
前后端怎么友好地对接口啊?
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
我前端,一般先大概评估需求 先定制接口 商量好字段 后段照着我说的给数据
|