谈谈前后分离接口规范
副标题[/!--empirenews.page--]
1. 前言 随着互联网的高速发展,前端页面的展示、交互体验越来越灵活、炫丽,响应体验也要求越来越高,后端服务的高并发、高可用、高性能、高扩展等特性的要求也愈加苛刻,从而导致前后端研发各自专注于自己擅长的领域深耕细作。 然而带来的另一个问题:前后端的对接界面双方却关注甚少,没有任何接口约定规范情况下各自干,导致我们在产品项目开发过程中,前后端的接口联调对接工作量占比在30%-50%左右,甚至会更高。往往前后端接口联调对接及系统间的联调对接都是整个产品项目研发的软肋。 本文的主要初衷就是规范约定先行,尽量避免沟通联调产生的不必要的问题,让大家身心愉快地专注于各自擅长的领域。 2. 为何要分离 目前现有前后端开发模式:“后端为主的MVC时代”,如下图所示: 后端为主的MVC时代 代码可维护性得到明显好转,MVC 是个非常好的协作模式,从架构层面让开发者懂得什么代码应该写在什么地方。为了让 View 层更简单干脆,还可以选择 Velocity、Freemaker 等模板,使得模板里写不了 Java 代码。看起来是功能变弱了,但正是这种限制使得前后端分工更清晰。然而依旧并不是那么清晰,这个阶段的典型问题是:
综上所述,就跟為什麼要代碼重構一樣:
3. 什么是分离 我们现在要做的前后分离第一阶段:“基于 Ajax 带来的 SPA 时代”,如图: 基于 Ajax 带来的 SPA 时代 这种模式下,前后端的分工非常清晰,前后端的关键协作点是 Ajax 接口。看起来是如此美妙,但回过头来看看的话,这与 JSP 时代区别不大。复杂度从服务端的 JSP 里移到了浏览器的 JavaScript,浏览器端变得很复杂。类似 Spring MVC,这个时代开始出现浏览器端的分层架构: 浏览器端的分层架构 对于这一SPA阶段,前后端分离有几个重要挑战:
4. 如何做分离 4.1 职责分离 职责分离
后端前端提供数据接收数据,返回数据处理业务逻辑处理渲染逻辑Server-side MVC架构Client-side MV* 架构代码跑在服务器上代码跑在浏览器上 4.2 开发流程
Mock 服务器根据接口文档自动生成 Mock 数据,实现了接口文档即API: 开发流程 4.3 具体实施 现在已基本完成了,接口方面的实施: 接口文档服务器:可实现接口变更实时同步给前端展示; Mock接口数据平台:可实现接口变更实时Mock数据给前端使用; (编辑:甘孜站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |