请问下各位 V 友，你们公司前端参与 API 接口定义么？

[SilentRhythm]

我司之前版本的 api 创建和修改，都是由后端定义的。这次技术 leader 突然来个后端只定义 url ，前端去补充入参出参，遇到了很多问题，诸如此类：

1 前后端对单词的理解不一致，如员工可用 companyUser/staff/employee 都行，并不能说谁错谁对
2 命名习惯如驼峰规范
3 后端返回包装类/分页固定包装类
4 后端基础字段如 createTime updateTime 等
5 后端 java ，前端 js 对类型不敏感，定义的都是 string 类型
6 POST 使用 query 参数类型


leader 的回应：执意前端参与接口定义并让我出术语表，并表示一回生两回熟，下次就不会犯错了。

我在想 如果我术语表都出来了，我不是接口都定义好了么。
就我个人而言，如果时间允许，我当然非常支持并热衷于这种有利于团队学习提高能力的工作内容。
但是据我了解当前版本的开发时间并不充裕，如果还要与前端扯皮字段命名，出术语表，到时加班的还是自己。

[esee]

不参与。谁定都行，就算用奥特曼名字做变量名我也能接受，规则定好比什么都强。

[tool2d]

你和 leader 说，一般字段都是后端定的。

如果非要前端来定，这算是部门合作损耗，要加钱。

[wu67]

我都经历过. 严格来讲, 前端定义字段也没什么问题. 甚至某种程度上, 前端给的用词可能更准确.

命名习惯方面, 严格来说, 还是小驼峰居多, 但是如果后端是搞 php 或者 c 出身的, 可能他就喜欢蛇形命名风格...

分页更应该有前端定. 因为可以直接套到 ui 框架里面, 而不用反复命名

对类型不敏感、全是 string. 那是你的问题...

post 用 url query 带参, 打一顿就好了. 建议是全部用 post, 参数全放 data, 除了上传文件, 统一用 json. ps: 用 get 来做修改操作的接口我也不是没见过, 一言难尽...

[lee122929]

一般不参与

[li746224]

一个接口如果有两个前端服务用的话，你们是不是先让两个前端打一架啊

[SilentRhythm]

@wu67 忘了说哈，我是后端。
我对前端定义字段并没有不满，更多的是对 leader 不满，交代前端定义接口后没有交代任何规范，摸石头过河。
最大的问题还是对实体理解的一致性，现在感觉就是一辆车有好几个方向盘，增加了很多沟通成本，后面还要赶开发进度，而且接口定义的字段命名最终还是要对齐数据库的。

[ljrdxs]

前端参与很正常啊。你 API 稍微改改，前端复杂度可能小很多。反之，你能想想 API 完全由前端定么？前端怎么爽怎么来，你肯么？
这种本来就要双方商量出一个相对好的方案。

“前端 js 对类型不敏感，定义的都是 string 类型”这个完全不应该。因为前端哪怕只用 JS ，也不止 string 类型。JSON 里面都分类型呢。
你看，你也需要和对方商量，请求对方修改。

[SilentRhythm]

@ljrdxs 是的，我同意前后端是需要相互协作沟通的。
一般来说以往是后端先出一个后端爽的版本，然后根据前端意见进行修改。

现在我司的情况是后端出一个版本，前端出一个版本，相互 battle ，加大沟通成本。
但我认为实际这个场面是 leader 造成的，而且他只需要为结果（版本按时上线）负责，沟通过程前后端都受罪 leader 才不管。

[juzisang]

后端定好给前端看一下不就行了吗，你们执行得这么严格，必须要前端手把手敲出来的吗...

[huangqihong]

前端参与属于正常吧，更好的参与到数据设计中，对于接口对接会更加熟悉

实际上呢，会加大前端的工作量吧，哪有空啊，前面写页面，后面对接口

[tool2d]

@juzisang 应该是前端和 leader 吐槽过后端权利过大，很多 API 后端拒绝修改，前端代码会复杂化，大数据量页面会卡顿。

要不然前端谁去扣英文单词拼写，API 直接拿来用就行了。

[qbmiller]

每次都前后一起，我们很多时候 都是前端主导(android ios) . 谁主导谁写 wiki 文档...

定好后，具体开发中 时不时，前后端 都需要加个参数 改个结构等...
前后是一家人，你要想，早晚你也是全栈

[LeegoYih]

流程有问题，我们都是设计方案评审的时候把所有命名对齐，接口也会定义出来，有分歧直接在会上达成一致。

[sgiyy]

完全由前端负责接口定义不合理，大部分的时候，前端并不熟悉后端表设计和业务逻辑，强行让前端接手只会增加双方的沟通时间。
最好还是开发前后端先出接口文档，然后双方再一起对，有需要的再改。互相配合点最重要。

[liahu]

后端定义啥我用啥，然后他们定义的名字就是我方法名或者变量名，省力，不用想变量名了！

[cnoder]

其实都行，看习惯吧，主要是怎么样把沟通成本降到最少

[dcdlove]

[卑微前端说说工作中遇到的情况]
[一] 最开始后端全按自己这么爽怎么定，前端得找到对应模块和接口编写得后端才能私下沟通着对接，因为 swagger 后端不写字段描述，或者干脆入参回参类型都不定义直接 object ，这种方式效率极其低下，而且很多业务让前端在获取数据后根据业务逻辑计算或过滤筛选出结果，却字段，或返回结构不合理，简直太频繁了，并且接口定义根本不按页面关系分类， 可能一个页面你要问好几个后端才能拼凑出来。一个 crud ，每个人写出来得名字都不同。add ，new ，create ，get post 随意乱来，甚者一个接口一部分参数 get 一部分 post 。
[二] 前后 leader 沟通约定了一个大致得样板，保证 crdu 命名能统一，注释能带上些，但是前端是 ts ，解析 swagger 自动生成接口，现在还是太乱没法生成，
[三] 让前端都学习完了 java springboot 掌握定义接口 swagger 文档 和 crud ，本页为完美了后端只需要实现服务把控制器返回结果实现就行了，太天真，人家直接返回了不这样弄就是要乱搞。到此，直接我放弃了，恢复到最原始的方法，接口随他们，没有就等不能用就等着。项目拖延就拖延。

[huajia2005]

我这边是想前端参与进来,但是很多前端并没有这个心思

[huajia2005]

其实前端参与进来一起讨论会好很多

[dcdlove]

期间尝试过用 postman 、Apifox 将每个接口的参数返回结果 模拟数据 各种枚举字典 都写成标准文档，在后端开写之前给到他们，然而人家就是不按文档来就是要弄点不一样就恶心你。期间后端还说用 magic-api 动态接口，也行，前端又傻乎乎学了 magic-api 并且编辑好出入参和接口，以及数据模拟，一个项目上百个接口 3-4 个端口接口啊，到了实际写出来人家又变卦了，你能怎样，一句话你越认真配合，越是欺负你，所以本质还是人，有的东西真的就不是人，还好意思当后端。