杭素文
肯定是不合理的，通常在前后端合作开发的时候，或者两个系统要做服务调用的时候，首先是要确认接口文档。现在我负责的一个项目，只提供查询服务，当我们在做一个新接口的时候，通常会提供这么几个时间点：提供接口文档的时间，联调测试的时间和正式提测的时间，可以看到接口文档肯定是要第一时间提供的。
在早期的项目开发中，开发人员要负责前端加后端的开发，一个人负责一个模块或者一个需求的时候，通常是需要从前端管到后端的，而前后端分离架构的出现，意味着开发人员的分离，每个开发人员会负责某一个领域的事情；而先确定接口文档最重要的一点，就是可以让所有的前端开发和后端开发并行工作，不然的话，就可能项目前期，前端开发人员闲着没事儿做，因为要等接口文档，而项目后期后端开发又没事儿做，因为要等前端开发好了才能提测。
所以，一定要文档确认，双方并行开发，再在一个时间点联调测试；系统和系统之间调用的场景也类似，也是要确认文档后，两个系统并行开发，在规定时间点开始联调测试。
在接口文档确认之后，建议前后端两方、或系统和系统两方的开发人员组织评审，两方认为文档没有什么问题后再进行开发，如果在开发过程中有不合理的地方，再对接口进行微调。
再说说我们项目，因为我们不是前后端分离的场景，只是对外提供服务，所以基本上都是服务提供方确定文档，不需要再做什么评审，当然在接口确认过程中也有几点要注意：
1. 遵守接口规范，如果公司有接口规范的话就最好了，可以节省很多不必要的麻烦；如果公司没有制定统一的规范，也至少在项目组内制定自己的规范。
2. 接口参数见名知意，我们对于 DTO 中的字段名称都是有统一规范的，比如性别就都叫 gender，如果是老项目的话，数据库中的表结构不容易修改，比如姓名字段已经起名叫做 sex 了，也建议在代码中对 Model/VO 转一次到 DTO。
3. 接口文档确认后，尽量不要做修改，这就意味着你在正式开发前，就要做评估和设计。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
会点代码的大叔
一个非常好的问题，我是工作多年的Web应用架构师，来回答一下这个问题。欢迎关注我，了解更多IT专业知识。
后端给出接口文档太晚，也合理也不合理，要看具体情况，总有解决方法，我来说一下我的观点。
不合理：成熟的技术团队，重视功能设计，在动手写代码之前已经有了完整的技术文档和功能定义，甚至在TDD测试驱动开发模式中，测试数据已经准备就绪，那么这时接口文档不管写没写，接口逻辑都是已经确定的，整理出来是水到渠成。
合理：多存在于早期小型创业公司，主观客观原因都有。
- 先说主观原因。赶进度、没时间、懒得写，甚至开发前都没做仔细的设计，边做边改，这些原因普遍存在，也实在没啥好办法。
- 客观原因，需求在变，功能跟着变，接口也要变，那么如果写了文档，理所当然也要更新维护啊？我的天哪。
有解决方法吗？建议试试：
1，Swagger接口文档，将文档融合到代码中，让维护文档和修改代码整合为一体，使得修改代码逻辑的同时方便的修改文档说明。
2，Postman接口测试工具，导入导出JSON文件，高效团队协作。Postman支持各种请求方式和配置环境变量，并对返回结果进行测试校验，支持批量自动化运行，可以和自动构建系统集成。
急速马力快de源码客
我觉得不太合理。说一下我的观点...
在需求已经定的情况下，后端开发应该优先根据原型图将接口定义(后续可以适当修改)好，并且提供对应的接口的文档。然后在前后端同学对提供的接口文档没有异议的情况下，可以并行开发。这样在字段名都定义好的前提下，前后端同学就不会在联调的时候互相甩锅了…这样也可以提高开发效率，避免后端同学闭门造车。同时也会增进同事之间的默契。还有就是如果后续前后端同时开发的时候，发现接口参数需要变动的话。也可以及时修改，避免重复造轮子。
事情都是要做的，要找到一个省心省力的办法解决问题。多为跟自己联调的同学考虑，给予对方最大帮助。
J小劲
肯定是不合理的，项目的整个研发流程还有前端还有测试，还有其他的后端人员，不可能通过口口相传来进行接口说明，所以必须要写接口文档。
从团队合作
如果项目是前后端分离架构的，那一定涉及到前端开发人员还有测试人员，还有其他后端开发人员，这些人都有需要去了解接口到的实现，如果不写接口文档，那这些人怎么办，如何了解到接口的设计，地址是什么，传参是什么，参数的长度、类型，是否是必传的，总不能天天问开发，如果是这样那就是给自己挖了一个大坑，优秀的开发是不会这样做的。即使不是前后分离，测试也没有，都由研发自己负责，那随着不断的迭代，接口越来越多，当需要去了解以前的接口设计时，就得回去看代码，自己也会疯掉，远不如看文档来的清晰明了。清晰明了的接口文档有助于团队之间的合作，其实也会为自己省去不少时间。
传承
互联网公司的流动性大，这是众所周知的，随着人员的流动，本来做这个接口的人员离职了，新接手的同学要想了解以前的接口，只能看代码，还是痛苦。再有新来的前端同学和测试同学想要了解接口，怎么办。
个人
程序员最讨厌的四件事情，不喜欢看别人的代码，不喜欢别人的代码没有注释，不喜欢自己写注释，不喜欢自己写文档。看似简单的接口文档，其实体现的是研发人员的接口设计能力，当输出到的接口文档不会被人挑刺，不会被问死，那说明设计能力已经不错了。而且写出优秀的文档本身也是对自己写作能力的一种锻炼，何乐不为呢。
质量
接口文档体现的是研发对这个接口实现的设计，当对业务需求、前后端交互有足够的理解，才能写出优秀的文档，这本身也是质量管理的非常重要的一个步骤。
总结
需求研发的过程每个组都会输出自己的文档，产品要输出合理详细的需求文档，研发输出优秀的设计文档和接口文档，测试输出完善的测试方案和覆盖全面的测试用例，各个环节都尽自己的努力输出该有的东西，相信产品的上线质量会好很多。
测试轩
后出文档的人应该没怎么做过前端，不理解为什么前后分离以及前后分离的优势，更不知道该如何协作，只是单纯认为出接口是个多余的劳动吧，我在公司推广了yapi，后端竟然还是还是不愿意写，每次该提测了，接口文档刚刚写好，其实就是postman请求然后贴到文档里，前端开发完全凭经验靠蒙，提测前改属性名，还得自测半天，最后还给前端提一些参数错误的bug，以后还是前后端一起搞比较好，项目划分
飙车族nbn
合不合理要看开发模式，前后端分离的，而且定义好了请求体和返回体，不合理，而且你要等全端要接口，说明你也不是一个好前端。要是后段驱动模式，就是说只给出业务需求的由后端实现的，那么很正常，毕竟后端为主，而且后段需要一个完整的业务流程接口开发完才能给到前端，毕竟数据是一个完整的流程，后段还要造数据接口才能调通
码小卒
不合理。文档永远是很重要的,降低沟通成本,提高开发效率:
- 可以使用swagger:
http://www.zhikestreet.com/content/p/29.html
- EOLINker: http://www.zhikestreet.com/content/p/6.html
顶级码农
这tm一点都不合理，这样前端开发就必须等他们搞完，这不是浪费了时间吗。
应该先定接口，然后各自开发。
古月大叔
这是个逻辑的问题。一般后端都是根据接口文档去开发的。前端也是同步根据接口文档对接的。所以一般开发之前接口文档都已经起草完毕。
对于你说的接口开发完成之后才去写文档的，不知道是什么情况。
农民小罗罗
SE设计的时候就应该把接口 业务 全部定下来。后端按照设计做。除了接口设计不合理要改也应该se改文档后前端修改，一切都应该有规有范。
小公司当我这些没说，自己协调扯皮吧。
