后端开发完接口才给接口定义, 是常规操作吗?

[Chingim]

最近加入了一个 1000 多人的中型公司, 在做项目的过程中, 后端不愿意先协商接口定义, 坚持等他开发完后才给接口文档, 理由是先给接口文档, 实现的过程中难免有变动, 改动起来很麻烦.

而作为前端, 我的理由是, 产品需求文档以及设计稿已经具备的情况下, 先约定接口定义, 前后端可以并行开发, 提高效率.

几番交涉之后还是没有达成一致, 现在是他开发一个接口, 给一个接口的文档.

之前就职的小公司是开发前给接口定义, 所有人评审接口之后再开发的. 我觉得效率很高, 定义好的接口, 开发过程中的改动也只是简单的增减, 不会有很大的变化.

是公司规模造成的开发流程差异吗? 请朋友们说说

我不是求认同, 也不需要 v 友站队.

我想要的是: 充分了解其他公司的协作流程, 充分了解其他后端同事对出具接口协议的看法，心智负担在何处。以及探讨怎么样才是合理的可实行的协作方案。

如果你没有探讨的想法，你可以保持沉默.

no war, make love

[bangq]

easymock 很方便，还是要提前约定的

[zjp]

我是这几天第一次和前端对接的新人...
公司现在的做法和楼主之前就职的公司一样，但是我在做实现的时候经常发现要改接口，前端也提了好几处修改...产品支持后端开发完才给接口文档其实对前端不是更有利吗

[kevinlm]

我是安卓，接了一个外包，后端让我们列出所需接口，然后他们才去写。妈的我想弄死他们，这帮鸟人压根不想动脑子。

[zhuzhibin]

应该是 先出接口文档 然后前端 mock 并行开发吧 最后才联调 ？

[Chingim]

@zhuzhibin 不要应该，说说贵司情况。

@zjp 有利很难说。如果急着上线，开始开发的时间越晚，你的心智压力就越大。而且开发完才给接口定义的话，改起来更麻烦。

[zhuzhibin]

@Chingim 我各种场景都有经历过。。。 我是后端出身 之前公司是写完接口 补文档 同步给前端 后面也是因为效率问题 前端不可能干等后端接口 项目赶的时候 效率会差 所以才说了上面的那个方式 而如今 我自己一个人撸完页面 自己写接口 自己对接口 over 我要继续搬砖了

[also24]

先出全部详细文档的话，对后端来说工作量确实比较大。

工期确实紧张的话，我一般会建议先约定好大致的接口分类，和每个接口包含的大致内容（具体结构暂不约定），这样在前期就可以先做功能逻辑推演，及早发现问题；至于细节部分就留在开发过程中解决。

[Chingim]

@zhuzhibin 全干工程师要注意身体，这都 23 点了。休息吧

[changdy]

前后端都是个小菜鸟发表下自己看法：
前端属于所见即所得，不会涉及太多的状态流转。
而后端并不完全所见即所得，经常在开发过程中修改结构和实现方式。
一般来说越是逻辑复杂和初始阶段的项目，后端越难给定义。

不过前端也不算是等到后端有定义了才开始能写页面吧。刚开始的时候也可以写写样式 dom 结构等等..

[zhuzhibin]

@Chingim 开玩笑的啦 我还是挺注意休息的躺床听歌睡觉了💤

[kidtest]

理想情况肯定是先沟通，两边技术对好方案，商量好接口，同步开发。但实际上两边的排期可能会有出入，所以，尽量不影响双方开发进度就好

[Chingim]

@changdy 对于一些富前端应用, 其实并不是单纯地进行状态的展示, 也存在状态的变化.

没有接口文档也不是不能开发, 只是在开发过程中定义的各种数据结构可能和最终的接口相距甚远. 当接口出来之后要多加一层适配器.

[Chingim]

@kidtest 嗯, 可能是我的要求太过于理想了.
我决定在前端维护一套数据模型, 接口定义好之后再写适配器进行转化. 试试效果

[hyyou2010]

这里面很可能是一个怕背锅的问题，比如现在商定好了，但后端以后需要更改一下，他怕你把责任都推到他头上。只要大家都理解这个研发工作存在不确定性，告诉后端不用担心背这种锅就好了。

[reus]

需求确定了，接口就能写出来了，实现时改接口，说明需求没有搞清楚，或者根本就没有试过去理解需求，就开始做了，那当然要一边做一边改。

这种后端就是个坑货

[ChefIsAwesome]

其实就两种情况：
页面长什么样，接口就给什么样。一般这都是后端套了一层的结果。
接口跟页面不一致。前端自己拼出需要的数据。

前端开发的时候，只要把 getData 和 render 分开就行了。对 render 来讲，getData 只是一个函数，总是返回自己需要的数据。getData 里头你返回假数据也好，取真正的接口也好，取几个接口再拼出来结果都跟 render 没关系。这样就灵活多了。

[AngryMagikarp]

如果真的要先给出全部文档，而且是那种不更改的，那要花很多时间，而且也绝不是后端自己就能定的，还要参考前端的意见，不然到时候还是大概率要改。你就说说你们以前的迭代规模，接口评审花了多少时间，效果如何。

另外就算要推动这一流程，绝不是后端程序员的事，找你们的技术总监。

很多公司连产品需求都要改来改去，更别说是接口了。

再其次，既然需求已经定了。某种意义上前端自己也能设计出一套接口，你们完全可以按照自己的思路先做，正常情况下，你们自己假想的接口和实际后端提供的，应该只是结构不同（字段名等）。如果有很多出路，很可能是你们的产品理解就不同，赶快开个会统一一下。

反正我无论是做客户端还是服务端，都会积极推动接口规范。我觉得接口不是只是后端的工作，前端也要积极参与其中。

[rizon]

这种事情，事实话和你说：

如果工期紧张，肯定是先出 mock 接口的（有各种 mock 接口平台就是为此而生的）。前后端并行开发。但是开发中，接口绝对改来改去的，这个不全是个人能力问题，总之接口变动是必然发生的。

如果工期不紧张，那公司要是允许你们等到后台开发完再出接口，其实对你们有好处不用改来改去，踩的雷后端自己踩个差不多了没让前端一起跟着踩。但是等接口联调的时候，如果前端对接口不满意说是这种方式做不到，那后端就会很被动了。而且在这种时候后端接口还是会有可能发生变化的，原因很复杂，只不过不像先出 mock 接口那么频繁。

[metrxqin]

我是服务端。

新需求首先由我这边出接口文档初版供应用端开发参考，之后将服务端实现部署至测试服务器，联调过程中决定是否迭代接口文档。

[Sanko]

每次让前端给我写文档的后端小菜鸡路过~

[Chingim]

@AngryMagikarp 所以先出接口文档，前端才能够从自身角度提意见，达成一致之后把坑都排除。
如果后端一直闭门造车，到时不能满足产品需要，变动起来岂不是更麻烦。

接口文档是前端参与接口建设的重要契机，如果开发完才提供，那就不是讨论，而只是通知了

[Sparetire]

以前公司都是前后端产品设计需求过完，后端花个一天设计接口，前后端再一起过一遍接口，定好接口文档，然后并行开发，接口偶尔有变动，但基本上变动不大，并且变动后及时更新接口文档通知对方
就这，我当时还觉得协作不顺畅。。看完楼上我想是我身在福中不知福

[frandy]

前端：原型图扫一遍 -> 画页面
后端: 原型图扫一遍 -> 抽取出给前端返回的数据和相关接口 -> 定义 VO->出 mock&实现具体逻辑
上面两者并发执行，之后联调，查缺补漏。

[frandy]

上面有提到出接口文档，emmm，有了 swagger，还要什么文档，代码即文档，具体不清楚的字段具体沟通。

[dajj]

按照经验， 首先技术方案确定，难点解决之后才能出第一版接口文档，
然后后期开发过程中，肯定要改动接口的。
那种认为需求定了，接口就定了，简直无知。 需求难道还规定了具体字段名？
举个例子， 页面中有个字段， 一开始想到用 英文 1, 后面发现其他人也用到，然后又改成 英文 2, 这是多么常见的现象。
如果前端不肯跟着变的话，我是不乐意先出文档的。

我觉得正常来说
开始开发前，可以先对前端页面进行讨论， 大概页面给几个接口，接口包含哪些数据。
后端做好开发设计， 解决难点和创建好数据库后， 可以给出大致的接口名和请求参数
后端初步开发完成后， 这时候可以给出具体的响应格式
最后联调阶段，再稍微调整接口

[scnace]

后端真是惨 明明是产品经理的锅 要被前端吐槽接口怎么老是改 /接口怎么还没给 还要被 DBA 怼这个人怎么老让我帮改表结构 被怼到可能还要被项目组 leader 说 block 项目进度…（互联网寒冬，请体谅下每一个还奋斗在一线的后端码畜 🌚

[akira]

1000 多人的中型公司 ，不会就你们 2 个研发吧，这个后端是典型的个人开发作风啊

[fakeshadow]

请问我这样前后自己来还不停改接口的，是不是逗逼。

[ackfin01]

怎么说呢，简单接口可以约定好定义，有些复杂的怎么给啊。所以一般是一部分给，让前端先忙起来，然后增量式开发完一个接口测的没问题给一个接口定义，这样增加效率，减少问题。

[johnhsm2333]

小外包公司提过无数次，但是后端接口写好了也不会写接口文档。每次开发都要被后端拖一拖进度。然后给骂。

[hantsy]

参考 CDC(Consumer Driven Contract) 开发， 首先一起协商，定义好前后端一致的 Contract，生成 stub。 前后自己各自做自己该做的事，自己实现，写测试去验证 contract, 前后端的工作可以说可以完全分开。

流行的 CDC 工具包括，pact.io 比较适合基于 REST/HTTP 的开发，语言支持丰富，另外 Spring Cloud Contract 比较适合 Spring 全家桶，支持更多协议，比如 AMQP，等。

后端开发过程中，部分成果可以部署到公司内部 staging 服务器（当然你应该在用 CI ），应该很容易提供 Swagger UI 的在线工具来查询 APIs。文档是什么鬼？

[luozic]

码农，而不是设计或者软件工程师就是这么干的

[passerbytiny]

请问，你们的项目经理 /开发主管 /系统工程师呢？没有这些，1000 多人跟 5 个人没啥区别。

[justfindu]

我都是先给接口文档. 整理接口文档就是整理自己思路. 然后前端模拟.

[Antihank]

请问阁下以前就职的小公司是哪家方便说一下吗，我准备一下面试材料。。。
1000 人的公司确实不应该了，开发团队规模是不是跟得上另说，小公司产品改来改去的哪有文档这么奢侈的

[Cbdy]

我是一个“前后端分离”的反对者，前后端最好由一个人开发，效率高

[yxcoder]

表示一直做有接口适配,随他怎么改接口

[lihongjie0209]

@reus 一个需求可以有 N 种实现，具体选哪一种是由开发人员，开发进度共同决定的，并不是说需求定好了， 代码基本也确定了

[dumbass]

我都是先写好页面，然后再和后端对接口。如果页面画完，接口还没出，就可以光明正大地摸鱼了（逃）

[reus]

@dajj 需求确定了，后端就可以根据需求写接口，接口就是传什么参数，返回什么，字段名是后端决定的。接口写好了，后面不是十分需要的话，是不会改字段名的，因为前端可能已经把字段名写入代码里了，你改名字，就是给前端添不必要的麻烦。其他人用了不同的字段名，就是因为你不肯先出文档，所以你才会认为“常见”。不好意思，先写文档的，根本就不会碰到这种破事。
另外，前后端分离的架构，接口应该是各种对象的 CRUD，加上一些特殊用途的，不是根据页面来的，根据页面那就是前后端耦合了。所以写文档，就是对业务本身的建模，主要是定义对象的字段等等，相当于后端的初步开发了，甚至可以根据字段定义自动生成文档。如果你的接口是按照页面来分，那页面需求变了你的接口也要跟着变，这就不是前后端分离的架构了，开发效率自然就低了，没法前后端并行开发的。

[lihongjie0209]

前端先写静态页
后端先设计表结构

然后就一个具体的功能点二者一同开发，这样后面的联调就比较简单了

[reus]

@lihongjie0209 我说的是前后端共同遵守的接口约定，参数是什么，返回是什么，先定下来，怎么实现是后面的事情。例如一个加法接口，参数就是加数和被加数，返回另一个数，文档就是参数叫什么名字，例如 A, B，怎么传，post josn 还是 query string 还是都支持，返回的是什么结构，等等。至于后端怎么实现加法，这个前端不需要关心。
如果你连要做的是加法而不是乘法，参数是两个而不是多个，都不能确定的话，那就是我说的“需求未明确”。

[Aprilming]

我们公司都是前端把静态页面写好，搞点假数据，后端负责后端开发以及前端的数据渲染。

[Godykc]

服务端进度领先前端一个迭代周期
前后端分离完全可以错开啊

[amwyyyy]

@frandy 我前公司就是这样，效率挺不错的

[reus]

@lihongjie0209 你把“表结构”换成“参数和返回”，写下来，就等于是给了文档了，前端就可以把字段写进代码了，表结构那是后端实现阶段的事情。

[lihongjie0209]

@reus 想多了， 你数据不按照页面的需求给， 前端不得骂死你？一个展示页面需要调用三个接口来组装数据？后端可以把接口设计的尽量通用，但是前端的复杂度就上升了。

WEB 层和页面耦合那是必然的，WEB 存在的意义就是展示页面。

我们要避免的是核心业务对象和展示层的耦合

[wweir]

没有任何技术难度的项目，咋搞都行，推荐做法是后端负责人写接口文档草案，前、后端、测试等所有相关部门审阅后人手一份，基于文档进行开发。

有（后端）技术挑战性的项目，后端现行，开发出大致解构后，前端再参与开发。前端初期更多应该是理解业务、简单画界面、设计交互（划重点）。

[lihongjie0209]

@reus 你要把所有的接口定下来， 那就意味着你要做出很多假设， 而且这些假设会有依赖关系， 一旦其中的一个假设改变， 那么会导致一组假设全部失效，那也就是说你的接口全需要改。

需求是确定的，但是开发员人对需求的理解是随着开发慢慢增加了， 你期望别人在项目开发前就理解全部的需求并且不产生任何误解，我能想到的也只有简单的 CURD 了

[a0000]

我们公司是需求确定好，后端先定义接口，客户端确认有没有什么问题，没有问题，后端造假数据，让客户端先用着。并行开发，10 几个人的小团队

[a0000]

我们不是所有的都列出来，按界面出接口，边写边出，理想状态是后端不影响客户端开发

[owt5008137]

一般来说我是会先给接口，再实现功能。不过不排除中间会调整的可能性。

[Chingim]

@frandy
@hantsy
swagger 暂时没见使用。这个可以慢慢推，不用 word 我已经知足。

@passerbytiny 产品和项目管理同意延长工期，所以就没再探讨了。


@Antihank 以前公司确实开心，swagger/postman/zepin/Invision/asana/circleci/quip 各种服务各种协作工具，可惜产品赚不到钱



@yxcoder 适配也是一种办法，但是不能推进接口的规范化

[reus]

@lihongjie0209 那这就是你们的架构的问题，你们还活在前后端耦合的蛮荒时代。一个页面调几次接口也算问题？

后端当然会组装数据，但这些数据是符合“模型”，而不是符合“页面”。例如时间字段，返回的就是时间戳，不是 YYYY-MM-DD 之类的具体格式，因为前端可能需要显示的是“ xxx 前”。关联的数据也可以通过复合的字段返回，尽量减少前端的组装工作。现在的前端复杂度本来就是上升的，早就不是单纯写 css + html + jquery 的时代了。有时接口数据不复合需求，需要组装一下，是常见的事情了。前后端耦合，整体来讲就是低效率的。根据页面分接口，那多个端的，你也另外做一套？

后端服务的对象不是单纯的“ web 层”，web 只是前端的一种。移动端你另外写接口？小程序你另外写接口？内部调用你另外写接口？人力不是这么浪费的。

[ala2008]

小公司，后台先出文档，前后端初步同意，进入开发。有修改或缺，及时补上。整个过程是保持沟通的

[reus]

@lihongjie0209 你以为 CRUD 简单？能把复杂的业务模型整理成纯粹的 CRUD 接口，给前端调用，这就是后端架构功力的体现。

要做“假设”，说明需求还没有厘清。厘清了，就不需要假设。整理需求直到接口显而易见，本来就是开发的正常过程。何况题主已经说了“产品需求文档以及设计稿已经具备”，设计稿都出来了，你还想怎么大改？产品设计可能改，这就是你不先整理接口的原因？

[yogogo]

我们是前端先画页面，后端同时写接口，前端画完页面，后端也差不多写好接口了，然后联调。

[AngryMagikarp]

@reus 接口完全不照顾页面，那么前端（尤其是移动端）用起来会很难受。比如一个页面有三张表的数据，可以使用三个接口，但那样前端就要考虑先调用哪个，先展示哪个，还是全部调完再展示。这个也跟 UI 设计有关系，UI 说要一个 loading 一起展示，还是三个 loading 分别展示？因此接口不可能不照顾页面设计，那样做的才是真正的坑货。

多个端写多种接口很正常，很多应用多端的需求本身就有区别，就算当前没有区别，以后也很可能会有区别，分开容易维护。我遇到两端用同一个接口的情况下，我也会提供两个 URL 给他们分别用，但内部实现是同一套代码，这样方便以后改。内部调用更是一定要另外写接口了，都说了是内部调用怎么可能和外部接口用同一个？

接口在正式上线前变更字段很正常，只是上线后不改。一旦上线，做的也一定是兼容的更改。

你说的那些接口约定其实前端自己也能定，为什么必须后端定？前端就没有看产品需求？显然不是的，归根到底是市面上 90%的前端都不具备这个能力，因此就强依赖于后端。时间多的话，完全可以让前后端都出一套接口方案，然后开个会统一一下。那样就没有任何问题了。接口是前端和后端通信的方式，并不是后端说了算的，把接口设计的责任完全推给后端也是推卸责任的行为。

就你说的那个时间戳格式问题，我遇到过多少个前端都希望后端替他们返回“ XX 前”格式的。现实中那种真正为技术考虑的人少之有少，大部分人都只是想减少自己的工作量。这点不分前后端。

我的观点是：做一个“差不多”的接口文档是没多大意义的，因为这个东西开完产品会议前后端脑子里都应该有。做一个“完备”的接口文档则要投入很大时间精力，（前端也要参加！）并不值得，如果你们公司并不在乎的话也可以搞，不过这是公司上层决定的事，没必要针对后端程序员。

[Chingim]

@AngryMagikarp 其实我也不排斥前端出接口, 但是很多后端的接口跟数据库是耦合的, 如果前端出具的接口跟数据库表结构 /字段命名 /字段类型相去甚远, 那后端能接受吗?

我是赞成前端参与接口建设的, 但是如果没有开发前的接口讨论, 那么很难说什么接口建设.

[ety001]

@reus 把锅都推给需求不明确，的确是个好方法。。。

[guyujiezi]

那个开发没有听说过 TDD 么？

开发完再给接口，也太随心所欲了

[ryonanamizu]

@kevinlm 我宁可这样

[Alex5467]

@reus 能说出这种话的你怕是也是一种坑货吧，那你咋不说需求改了，产品也是坑货呢

[Gea]

小公司，小业务，当然可以先出文档了，如果业务足够简单，不需要看之前的代码，不需要调用其他服务，评审会上都能给出接口定义，如果你现在的公司是这样的，那喷一下后端我觉得有理。

大公司，复杂业务，前端状态复杂，后端也要多服务调用，你一开始给出接口定义，到最后开发出来可能完全不一样，或者很大一部分不一样，再调再改的话，接口定义很没意义也很蛋疼。

其次，写一个接口给一个接口文档提供给前端，你自己都不觉得很打乱开发节奏吗，后端要做的是: 看之前的代码=>结合需求，做业务 balabalabala=>提供文档，再循环往复。需要反复的思维转换，我觉得很影响开发效率。

最后我觉得还是看业务的情况，公司规模大小。一个前端转后端，小公司大公司都待过的我是这么觉得的

[Alex5467]

@AngryMagikarp 同意加一

[AngryMagikarp]

在某些人眼里，产品需求明确了，接口文档下一秒就应该出了，不出就是能力不行。

在实际中，只要不影响开发进度，我并不关心他什么时候出。很多时候都是可以先作页面的，大部分简单的接口后端也能在前端需要之前就给出。一个项目的开发是多方面的合作，而不是谁要顺着谁。如果后端接口开发真的慢，也应该反应到上级，才能让他们调整开发流程。

互相理解互相帮助，及时沟通才是正解。当然这是理想情况下。

[DavidNineRoc]

我感觉楼上是不是理解错了? >>>前端不得骂死你？一个展示页面需要调用三个接口来组装数据？>>>
一个页面只给一个接口的真是神人, 我只能这样说.
我司的做法:
UI 出设计图 => 前端画页面 && 后端写接口 ==> 后端给接口文档 && 前端渲染数据 ====> 稍后不同步, 前端做其他模块的页面, 后端开发其他模块的接口.

[reus]

@Alex5467 瞎鸡巴改需求，当然也是坑啊，有什么问题？

[AngryMagikarp]

@DavidNineRoc 我随便举了个例子，说一个页面三个接口的情况，你的理解就是一个页面必须一个接口？你的阅读理解才是神。

[reus]

@AngryMagikarp 我可没有说完全不顾，像一个页面需要三个接口的数据，那一起发过来，一起返回，甚至做更复杂一些的处理，都不是什么大问题。一次请求对应多个接口调用，这个可以实现成通用的机制。

内部调用和外部调用的方式可以有不同，但基本的参数和返回字段，难不成还用不同的？总得提前决定吧，后端之间也等实现了，才来改字段名或者加适配层？

接口可以有通用的，就是一堆 CRUD 的，可以有非通用的，例如只给某些页面或者终端用的。通用的，在初期就给出文档，不难吧？非通用的，可以在后面根据需求增加。至于前端还是后端写，需不需要讨论，这些都不是重点。楼主说的是后端在“实现”了接口之后才给文档，你真的觉得这样合适？

要加个格式化的时间字段，也不是大问题。注意是“加”，不是“改”，后端加了，你想用就用不想用就不用，不影响协作。

这一套流程不是我发明的，这里其他人一样有使用同样流程的。我们用得轻松愉快，不然楼主也不会发帖了对吧？

[reus]

@ety001 就事论事，连设计稿都出了的情况下，如果谁还说需求不明确，那这个团队的开发能力，绝对有大问题。

[Gea]

还有让返回 xx 前的？数据完全不复用？完全不能二次使用，只用来渲染？客户端性能全部用来渲染，不做一点计算，全部交给服务端计算？

[atonku]

@Sparetire 你这明显不是套路啊，应该是这样的：
后端花个一天设计接口，前后端再一起花一天过一遍接口，定好接口文档，然后第三天上线。

[DavidNineRoc]

@AngryMagikarp 说话不能好好说, 动不动就阅读理解有问题, 自己阅读理解有问题吧? 自己把 三个大于号之间的文字复制,搜索. 看我是和你说还是和另外的人说. 这是理解障碍?

[reus]

@AngryMagikarp “大部分简单的接口后端也能在前端需要之前就给出”，这不就是楼主想要的吗？？问题就在于楼主连这个都拿不到，完全等后端开发完接口了，才有！

[reus]

@AngryMagikarp 我希望你能理解“能写出来”和“下一秒就应该出”的区别。

[siteshen]

@kevinlm 我是后端开发，也遇到过这样的后端，也想拍死这种不负责任的后端。

[aa1072551507]

在我的小公司 都是我前端写先完页面 然后我把需要的接口格式写文档给后台人员 最后后天才开始写接口哈哈....

[IvanLi127]

这人数。。直接怼，没文档你没办法开发。或者你约定 api 文档，重新调整人员分配。编码明显是在这些东西之后的，他反驳你，你就质疑他专业能力

[947211232]

理应新定好接口再开发

[rockagen]

前端还是图样图森破，对一个 http 业务请求到后端的复杂度一无所知，按你们的公司的人数来看的话，内部系统应该是解耦合的，后端拿到需求是要去其他部门沟通 RPC 接口的吧，只能说后端能先实现大体流程，保证业务能跑通的同时输出接口，细节部分放后面去优化。好了，我要上台拿衣服去了。

[lihongjie0209]

@reus 就一句话 多个接口怎么保证事务？
后端把 post 拆分为 post1 post2 post3， 前端怎么做事务？

[lihongjie0209]

@reus 不好意思， 我们多端还真是多个接口的， 我们只需要保证核心的领域逻辑不变， 适配任何端都是可以的。

至于你说的 web 和页面耦合， 我这套接口就是给 web 页面做的， 只要由这种需求，那么我也会把 xxx 前 返回给前端， 因为类似小程序你要改 UI 还需要重新发布。

[lihongjie0209]

@Chingim 套一个 DTO 的事情

[reus]

@lihongjie0209 谁和你说要这样拆了？事务当然是一个接口啊。

你钱多或者接口少，当然可以一种终端一套接口。后端完全没有文档的不也有么。

[xuanbg]

当然应该先定文档再来按文档实现咯，你们的后端太菜，缺少自信。

[sichuyoudang312]

同 23 楼

[reus]

@lihongjie0209 “套一个 DTO 的事情”，说得轻松，假如有上百种类型，每个类型平均 10 个字段好了，那就是上千个，一个个手工适配？本来不需要干这种活的，就因为后端不肯先约定接口，就要做无谓的工作。

[lihongjie0209]

@reus 那用户端的和后台管理的对于 事务 X 的定义是一样的吗？

接口：

/api/doX


前端用户执行之后需要发送短信通知


后台管理执行之后不需要


一个接口如何实现这两个功能？

[lihongjie0209]

@reus 代码生成了解一下， 本来把数据库的结构暴露给前端就是一个很 sb 的事情

[alakey1989]

@Cbdy 可爱

[Chingim]

@lihongjie0209 你太理想了，接口字段名称 /类型和数据库耦合是常见的(虽然很不合理)

曾经沟通过接口字段的语义化，被“数据库里就是这么存的“搪塞过去了


@rockagen 接口是对外的服务，应该隐藏所有内部的复杂性不是吗？如果因为技术不可行，那在产品评审阶段就砍掉需求了。如果有调研的需要，那这部分前后端都可以暂停开发这部分功能。其余部分的接口还是可以先协商的吧？

[kulove]

开发完再给接口定义，不然难免会有改动且会有考虑不周的地方。
应该是后端对照产品原型开发，同时 UI 设计，基本 UI 图给到前端的时候后端接口也开发完了。

[Chingim]

@kulove 那如果开发完发现对需求的理解有偏差呢，那岂不是推倒重来。开发前协商接口，其实就是统一了对需求的理解，双方都有照亮认知盲区的机会

[lihongjie0209]

@Chingim 字段名称和我说的数据库结构是两回事

数据库结构是你的表结构是怎么设计的

如果把表结构对于的实体类直接返回给前端， 那么前端拿到的数据会有很多冗余，并且嵌套层级非常深


我一般的做法就是按照 UI 图单独定义一个 Response 类，返回一个扁平的对象，这样做的好处
1. 网络传输的数据少
2. 客户端只依赖于 Response， 不依赖于我的数据库结构
3. 前端写起来简单一点

[reus]

@lihongjie0209 你这个接口的逻辑，可以用一句话概括：doX，然后根据条件判断是否需要发通知。一句话能概括，那当然能一个接口实现，加个条件判断而已啊。前端有的用户想发短信，有的不想发，你也拆两种接口？有的用户想发短信，有的用户想发邮件，你也拆两种接口？这是一个功能，不是两个功能。

我觉得你根本就没有理解，我说的是接口的参数和返回，从来没有说“数据库的结构”，接口字段和数据库字段，不是必须对应的。代码生成有什么用？你前端用了 gender，结果后端接口用了 sex，代码生成怎么直到这两个字段是对应的？还不是要一个个对。

[kulove]

@Chingim 肯定是前后端都开会过了产品需求再开发，开发过程中发现逻辑 bug 及时反馈。

[lihongjie0209]

@reus
那安卓用户要推送消息并且同步记录到数据分析平台怎么实现？
你这个接口的职责有多少？
依赖关系有多复杂？
单一职责原则忘记了？

[reus]

@lihongjie0209 所谓的“给接口定义”，就是你把 Response 类的定义写出来之后，就给前端看，让他知道这个对象长什么样，就这么简单，后面你再实现。这样前端后端就可以达到题主说的“并行开发”。

[kulove]

事实上，开发完成后给接口文档并不怎么会产生偏差，如果经常有很大偏差，要么是默契度不够，磨合一段时间就好了，要么就是太菜。