共计 1018 个字符，预计需要花费 3 分钟才能阅读完成。
软件工程的两种办法下，由后端决定接口都是不对的。
第一种软件工程的办法：瀑布模型，自顶而下，逐渐细化。
接口会变，然而接口要提前设计。接口不是后端开发实现之后才“天然”产生的，那不是天然，而是无序。
前后端拆散的开发，应该是面向“API”的开发。API 的设计并不能由前端或后端一方决定或主导，而是须要一个前后端都相熟的人，这个人叫架构师。
随着最近几年前端技术的高速倒退和浏览器性能的晋升，前端可能实现的事件越来越多，前后端的分工也在变动。原来必须在后端实现的事件，当初放在前端可能更简略更天然，而且缩小了前后端之间的交互。
具体哪些性能放在前端，哪些性能放在后端，Restful API 的 URL 和申请参数、返回体，都应该由架构师依据需要提前设计。而后给前后端一起解说、探讨、批改。
当然，相对不奢求 API 老古不变，因为大家的能力也都在成长，教训也都在累积，必定有考虑不周全的中央。
第二种软件工程的办法：原型法，先确定需要，而后小步迭代。
如在在没有这样能前后端通盘考虑的架构师在的状况下，我更偏向于由前端决定前后端交互的 API 接口。
原型法，就是尽快产生能够验证的原型，起到辅助和用户（产品经理）探讨的作用，帮忙明确用户的需要。再也没有界面可能让用户直观感触的货色了，因为对于用户来说界面就是所有。而当初的前端齐全能够不依赖任何服务器端数据就能开发出界面原型（不是线框图），这个界面原型确定之后，也是前期前端开发的根底。
前端先开发界面原型。在确定界面风格、布局、跳转、交互的过程中，天然会行程须要获取数据的接口。这些接口是前端实在须要的。
如果在没有前端，或者后端开发基本不思考前端的状况下，本人写完后端代码产生的 API，是设想前端须要的 API，而且是齐全站在后端技术角度设想的。前端调用的时候必然顺当，甚至齐全不能满足需要。比方后端可能还依照本人以前写 JSP 时候的教训去提供 API，然而现在曾经齐全变了。
后端开发完接口才给出接口文档，是旧有开发模式遗留下来的开发方式。在前端没有成长起来之前，甚至没有前端的概念的时候，只有服务器端，当然是后端本人确定本人的借口了，而且确定的是 JSP 和 Controller 之间的接口（我仅以 Java Web 开发举例，其余技术都差不多）。
最初，举荐一款实用的 API 开发工具，叫 Eolinker 不论是没有架构师的小团队，还是 API 需要简单须要提高效率的大团队，不同的性能都能满足应用。
应用地址：www.eolinker.com