后端开发完接口才给出接口文档，合理吗？

软件工程的两种方法下，由后端决定接口都是不对的。
第一种软件工程的方法：瀑布模型，自顶而下，逐步细化。
接口会变，但是接口要提前设计。接口不是后端开发完成之后才“自然”产生的，那不是自然，而是无序。
前后端分离的开发，应该是面向“API”的开发。API的设计并不能由前端或后端一方决定或主导，而是需要一个前后端都熟悉的人，这个人叫架构师。
随着最近几年前端技术的高速发展和浏览器性能的提升，前端能够实现的事情越来越多，前后端的分工也在变化。原来必须在后端完成的事情，现在放在前端可能更简单更自然，而且减少了前后端之间的交互。
具体哪些功能放在前端，哪些功能放在后端，Restful API的URL和请求参数、返回体，都应该由架构师根据需求提前设计。然后给前后端一起讲解、讨论、修改。
当然，绝对不奢求API老古不变，因为大家的能力也都在成长，经验也都在累积，肯定有考虑不周全的地方。

第二种软件工程的方法：原型法，先确定需求，然后小步迭代。
如在在没有这样能前后端通盘考虑的架构师在的情况下，我更倾向于由前端决定前后端交互的API接口。
原型法，就是尽快产生可以验证的原型，起到辅助和用户（产品经理）讨论的作用，帮助明确用户的需求。再也没有界面能够让用户直观感受的东西了，因为对于用户来说界面就是一切。而现在的前端完全可以不依赖任何服务器端数据就能开发出界面原型（不是线框图），这个界面原型确定之后，也是后期前端开发的基础。
前端先开发界面原型。在确定界面风格、布局、跳转、交互的过程中，自然会行程需要获取数据的接口。这些接口是前端真实需要的。
如果在没有前端，或者后端开发根本不考虑前端的情况下，自己写完后端代码产生的API，是想象前端需要的API，而且是完全站在后端技术角度想象的。前端调用的时候必然别扭，甚至完全不能满足需要。比如后端可能还按照自己以前写JSP时候的经验去提供API，但是如今已经完全变了。

后端开发完接口才给出接口文档，是旧有开发模式遗留下来的开发方式。在前端没有成长起来之前，甚至没有前端的概念的时候，只有服务器端，当然是后端自己确定自己的借口了，而且确定的是JSP和Controller之间的接口（我仅以Java Web开发举例，其他技术都差不多）。

最后，推荐一款实用的API开发工具，叫Eolinker不管是没有架构师的小团队，还是API需求复杂需要提高效率的大团队，不同的功能都能满足使用。
使用地址：www.eolinker.com