这是一个创建于 483 天前的主题，其中的信息可能已经有所发展或是发生改变。
我司之前版本的 api 创建和修改，都是由后端定义的。这次技术 leader 突然来个后端只定义 url ，前端去补充入参出参，遇到了很多问题，诸如此类：
1 前后端对单词的理解不一致，如员工可用 companyUser/staff/employee 都行，并不能说谁错谁对
2 命名习惯如驼峰规范
3 后端返回包装类/分页固定包装类
4 后端基础字段如 createTime updateTime 等
5 后端 java ，前端 js 对类型不敏感，定义的都是 string 类型
6 POST 使用 query 参数类型
leader 的回应：执意前端参与接口定义并让我出术语表，并表示一回生两回熟，下次就不会犯错了。
我在想 如果我术语表都出来了，我不是接口都定义好了么。
就我个人而言，如果时间允许，我当然非常支持并热衷于这种有利于团队学习提高能力的工作内容。
但是据我了解当前版本的开发时间并不充裕，如果还要与前端扯皮字段命名，出术语表，到时加班的还是自己。
1 前后端对单词的理解不一致，如员工可用 companyUser/staff/employee 都行，并不能说谁错谁对
2 命名习惯如驼峰规范
3 后端返回包装类/分页固定包装类
4 后端基础字段如 createTime updateTime 等
5 后端 java ，前端 js 对类型不敏感，定义的都是 string 类型
6 POST 使用 query 参数类型
leader 的回应：执意前端参与接口定义并让我出术语表，并表示一回生两回熟，下次就不会犯错了。
我在想 如果我术语表都出来了，我不是接口都定义好了么。
就我个人而言，如果时间允许，我当然非常支持并热衷于这种有利于团队学习提高能力的工作内容。
但是据我了解当前版本的开发时间并不充裕，如果还要与前端扯皮字段命名，出术语表，到时加班的还是自己。
 |
1
esee 2023-07-14 15:33:30 +08:00  1
不参与。谁定都行，就算用奥特曼名字做变量名我也能接受，规则定好比什么都强。
|
 |
2
tool2d 2023-07-14 15:35:23 +08:00
你和 leader 说，一般字段都是后端定的。
如果非要前端来定，这算是部门合作损耗，要加钱。 |
 |
3
wu67 2023-07-14 15:41:18 +08:00
我都经历过. 严格来讲, 前端定义字段也没什么问题. 甚至某种程度上, 前端给的用词可能更准确.
命名习惯方面, 严格来说, 还是小驼峰居多, 但是如果后端是搞 php 或者 c 出身的, 可能他就喜欢蛇形命名风格... 分页更应该有前端定. 因为可以直接套到 ui 框架里面, 而不用反复命名 对类型不敏感、全是 string. 那是你的问题... post 用 url query 带参, 打一顿就好了. 建议是全部用 post, 参数全放 data, 除了上传文件, 统一用 json. ps: 用 get 来做修改操作的接口我也不是没见过, 一言难尽... |
 |
4
lee122929 2023-07-14 15:45:37 +08:00
一般不参与
|
 |
5
li746224 2023-07-14 15:47:06 +08:00 1
一个接口如果有两个前端服务用的话，你们是不是先让两个前端打一架啊
|
 |
6
SilentRhythm OP @wu67 忘了说哈，我是后端。
我对前端定义字段并没有不满，更多的是对 leader 不满，交代前端定义接口后没有交代任何规范，摸石头过河。 最大的问题还是对实体理解的一致性，现在感觉就是一辆车有好几个方向盘，增加了很多沟通成本，后面还要赶开发进度，而且接口定义的字段命名最终还是要对齐数据库的。 |
 |
7
ljrdxs 2023-07-14 15:50:34 +08:00
前端参与很正常啊。你 API 稍微改改，前端复杂度可能小很多。反之，你能想想 API 完全由前端定么？前端怎么爽怎么来，你肯么？
这种本来就要双方商量出一个相对好的方案。 “前端 js 对类型不敏感，定义的都是 string 类型”这个完全不应该。因为前端哪怕只用 JS ，也不止 string 类型。JSON 里面都分类型呢。 你看，你也需要和对方商量，请求对方修改。 |
|
8
SilentRhythm OP @ljrdxs 是的，我同意前后端是需要相互协作沟通的。
一般来说以往是后端先出一个后端爽的版本，然后根据前端意见进行修改。 现在我司的情况是后端出一个版本，前端出一个版本，相互 battle ，加大沟通成本。 但我认为实际这个场面是 leader 造成的，而且他只需要为结果（版本按时上线）负责，沟通过程前后端都受罪 leader 才不管。 |
 |
9
juzisang 2023-07-14 16:10:19 +08:00
后端定好给前端看一下不就行了吗，你们执行得这么严格，必须要前端手把手敲出来的吗...
|
 |
10
huangqihong 2023-07-14 16:24:00 +08:00
前端参与属于正常吧，更好的参与到数据设计中，对于接口对接会更加熟悉
实际上呢，会加大前端的工作量吧，哪有空啊，前面写页面，后面对接口 |
|
11
tool2d 2023-07-14 16:26:55 +08:00 1
|
 |
12
qbmiller 2023-07-14 16:31:47 +08:00
每次都前后一起，我们很多时候 都是前端主导(android ios) . 谁主导谁写 wiki 文档...
定好后，具体开发中 时不时，前后端 都需要加个参数 改个结构等... 前后是一家人，你要想，早晚你也是全栈 |
 |
13
LeegoYih 2023-07-14 16:36:25 +08:00
流程有问题，我们都是设计方案评审的时候把所有命名对齐，接口也会定义出来，有分歧直接在会上达成一致。
|
 |
14
sgiyy 2023-07-14 16:44:59 +08:00
完全由前端负责接口定义不合理，大部分的时候，前端并不熟悉后端表设计和业务逻辑，强行让前端接手只会增加双方的沟通时间。
最好还是开发前后端先出接口文档，然后双方再一起对，有需要的再改。互相配合点最重要。 |
 |
15
liahu 2023-07-14 16:46:19 +08:00
后端定义啥我用啥，然后他们定义的名字就是我方法名或者变量名，省力，不用想变量名了！
|
 |
16
cnoder 2023-07-14 17:27:04 +08:00
其实都行，看习惯吧，主要是怎么样把沟通成本降到最少
|
 |
17
dcdlove 2023-07-14 17:29:20 +08:00
[卑微前端说说工作中遇到的情况]
[一] 最开始后端全按自己这么爽怎么定，前端得找到对应模块和接口编写得后端才能私下沟通着对接，因为 swagger 后端不写字段描述，或者干脆入参回参类型都不定义直接 object ，这种方式效率极其低下，而且很多业务让前端在获取数据后根据业务逻辑计算或过滤筛选出结果，却字段，或返回结构不合理，简直太频繁了，并且接口定义根本不按页面关系分类， 可能一个页面你要问好几个后端才能拼凑出来。一个 crud ，每个人写出来得名字都不同。add ，new ，create ，get post 随意乱来，甚者一个接口一部分参数 get 一部分 post 。 [二] 前后 leader 沟通约定了一个大致得样板，保证 crdu 命名能统一，注释能带上些，但是前端是 ts ，解析 swagger 自动生成接口，现在还是太乱没法生成， [三] 让前端都学习完了 java springboot 掌握定义接口 swagger 文档 和 crud ，本页为完美了后端只需要实现服务把控制器返回结果实现就行了，太天真，人家直接返回了不这样弄就是要乱搞。到此，直接我放弃了，恢复到最原始的方法，接口随他们，没有就等不能用就等着。项目拖延就拖延。 |
 |
18
huajia2005 2023-07-14 17:30:11 +08:00
我这边是想前端参与进来,但是很多前端并没有这个心思
|
|
19
huajia2005 2023-07-14 17:30:34 +08:00
其实前端参与进来一起讨论会好很多
|
|
20
dcdlove 2023-07-14 17:36:25 +08:00 2
期间尝试过用 postman 、Apifox 将每个接口的参数返回结果 模拟数据 各种枚举字典 都写成标准文档，在后端开写之前给到他们，然而人家就是不按文档来就是要弄点不一样就恶心你。期间后端还说用 magic-api 动态接口，也行，前端又傻乎乎学了 magic-api 并且编辑好出入参和接口，以及数据模拟，一个项目上百个接口 3-4 个端口接口啊，到了实际写出来人家又变卦了，你能怎样，一句话你越认真配合，越是欺负你，所以本质还是人，有的东西真的就不是人，还好意思当后端。
|
 |
21
IvanLi127 2023-07-14 17:38:42 +08:00 via Android
看你们项目的定位是啥了，web 后端的话，那肯定不能没有前端参与，除非做的是管理后台
重前端的话，全部前端定也是有的，定 API 这事肯定是跨在两头的人做，如果没这个人，那么要么变成这个人，要么两头的人一起定，一方定的话，另一方怕是要加班哦 |
|
22
dcdlove 2023-07-14 17:39:48 +08:00
@cnoder 我们公司是故意制造沟通成本，一个接口写完乱七八糟不说，不参照页面来写，就说好了，对接时候发现少字段，他们在去加，又等着，然后加了又各种报错，然后又等，反反复复 4-5 次，期间还要让测试参与，一个 10 分钟对接任务活生生弄一天
|
 |
23
lasuar 2023-07-14 17:44:35 +08:00
是很简单的 API 也可以，但总体来说，API 字段定义也涉及到具体实现逻辑，这必然是后端才了解的，交给前端定义不是合理的。
|
 |
24
pixiaotiao 2023-07-14 17:55:37 +08:00
现代 js 类型还是有影响的
|
 |
25
openliucongbx 2023-07-14 17:55:41 +08:00
不都是谁定都可以吗,大家配合下就行
做开发的还内斗的那么厉害吗 |
 |
26
han3sui 2023-07-14 18:46:10 +08:00 via Android
前端一般只对部分接口返回结构有要求
|
 |
27
AyaseEri 2023-07-15 00:25:34 +08:00
领导要求参与，但我一般懒得定，我实在懒得去纠结与争论应该用什么词。我只会说我需要什么信息。
感觉后端对接口命名、字段命名、文件夹命名更加在意？前端一般是 Model 派生出多个 ViewModel 后容易导致词不够用。 你怕是没碰到过领导要求前端评审后端 SQL 的，我一臭切图的哪敢吭声。 |
 |
28
zoharSoul 2023-07-15 00:55:10 +08:00
羡慕啊
一直想让前端出 |
 |
29
lanlanye 2023-07-15 01:21:18 +08:00
REST 一把梭，感觉你们的问题在于缺乏标准，与其自己订一套，不如直接找个现成的，比如 Google Cloud API Design.
|
 |
30
realpg 2023-07-15 09:15:37 +08:00
俩前端干起来咋办
|
 |
31
dengshen 2023-07-15 09:22:00 +08:00 via iPhone
已经无所谓啦。只求 tm 文档能写清楚一点。写的跟实际用的都对不上。什么勾八玩意
|
 |
32
cdswyda 2023-07-15 12:49:09 +08:00
开放 api 的话，按业务来，基本是要多部门评审的。
页面的接口的话，全部前端定啊，因为这样定好接口出来直接就能用，省 n 多事情。 1 、2 、3 是规范层面的事情，不管谁定，公司应该要有标准，比如什么格式，怎么用。 “4 后端基础字段如 createTime updateTime 等。 ” 这个完全不赞同，不管底层数据库怎么加，没有使用需求的话，接口没必要把这类信息暴露出来。 “5 后端 java ，前端 js 对类型不敏感，定义的都是 string 类型”。 既然是给前端用的接口了，输出不都是 json 嘛， 能用的也就字符串、数字和布尔值了。 如果数字和布尔都没出现过，那确实有有问题。 6 同 1 、2 、3 公司规范层面的事情，和接口自动定义关系不大 |
 |
33
weilanwl 2023-07-15 14:37:03 +08:00
我是前端，一般不参与。但是我主导的模块，我就会直接用 apifox 之类的工具先写好接口再给后端。
|
Select Language