前后端分离并不是什么新鲜事,到处都是前后端分离的实践。然而一些历史项目在从一体化 Web 设计转向前后端分离的架构时,仍然不可避免的会遇到各种各样的问题。
由于层出不穷的问题,甚至会有团队质疑,一体化好好的,为什么要前后端分离?
说到底,并不是前后分离不好,只是可能不适合,或者说……设计思维还没有转变过来…
比为什么要前后端分离更现实的问题是什么时候需要前后端分离,即前后端分离的应用场景。
1) 由于分离,Web 前端在开发的时候压根不需要了解后端是用的什么技术,只需要后端提供了什么样的接口可以用来做什么事情就好,什么 C#/ASP.NET、Java/JEE、数据库……这些技术可以统统不去了解。
2) 而后端的 .Java 团队也脱离了逻辑无关的美学思维,不需要面对美工精细的界面设计约束,也不需要在思考逻辑实现的同时还要去考虑页面上怎么布局的问题,只需要处理自己擅长的逻辑和数据就好。
3) 前后端分离之后,两端的开发人员都轻松不少,由于技术和业务都更专注,开发效率也提高了。分离带来的好处渐渐体现出来。
前后职责分离,彻底解放前端,前端不再需要向后台提供模板或是后台在前端html中嵌入后台代码。
前后技术分离,提高工作效率,分工更加明确。
用户体验和业务处理解耦
可以分别归约两端的设计
降低维护成本
任何技术方案都不是银弹,前后分离不仅带来好处,也带来矛盾。
前端处理过程中常常发现接口定义不符合用户操作流程,AJAX 异步请求过多等问题。毕竟后端思维和前端思维还是有所不同——前端思维倾向于用户体验,而后端思维则更倾向于业务的技术实现。除此之外,前后分离在安全性上的要求也略有不同。由于前后分离本质上是一种 SOA 架构,所以在授权上也需要按 SOA 架构的方式来思考。Cookie/Session 的方式虽然可用,但并不是特别合适,相对来说,基于 Token 的认证则更适合一些。
采用基于 Token 的认证就意味着后端的认证部分需要重写……后端当然不想重写,于是会将皮球踢给前端来让前端想办法实现基于 Cookie/Session 的认证……于是前端开始报怨(悲剧)……
接口设计
用户认证
跨域问题
1. 接口设计
从前端的角度来看,重点关注的是用户体验,包括用户在进行业务操作时的流动方向和相关处理。而从后端的角度来看,重点关注的是数据完整、有效、安全。矛盾在于双方关注点不同,信息不对称,还各有私心。解决这些矛盾的着眼点就是接口设计。
接口设计时,其粒度的大小往往代表了前后端工作量的大小(非绝对,这和整体架构有关)。
接口粒度太小,前端要处理的事情就多,尤其是对各种异步处理就可能会感到应接不暇。
粒度太大,就会出现高耦合,降低灵活性和扩展性,当然这种情况下后端的工作就轻松不了。
形式:Web API 可以定义成 REST,也可以是 RPC,只要前后端商议确定下来就行。
1. 键值对,用于 URL 中的 QueryString 或者 POST 等方法的 Payload。
2. XML/JSON/...,通常用于 POST 等方法的 Payload,也可以使用 multipart 传递。
3. ROUTE,由后端路由解析 URL 取得,在 RESTful 中常用。
1. 状态码,HTTP 状态码或响应数据中特定的状态属性。
2. 消息,通常是放在响应内容中,作为数据的一部分。
3. 数据,根据接口协议,可能是各种格式,当前最流行的是 JSON。
- 用户认证
基于 Cookie/Session 的认证方案
基于 OAuth 的认证方案
基于 Token/JWT 的认证方案
基于 Cookie/Session 的认证方案
采用传统的 Cookie/Session 认证方案并非不可行,只不过有一些限制。
如果前端部分和后端部分同源,比如页面发布在 http://domain.name/,而 Web API 发布在 http://domain.name/api/。
这种情况下,原来的一体式 Web 方案所采用的 Cookie/Session 方案可以直接迁移过来,毫无压力。但是如果前面发布和 API 发布不同源,这种方法处理起来就复杂了。
然后一般前后端分离的开发方式,不管是开发阶段还是发布阶段,不同源的可能性占绝大比例,所以认证方案通常会使用与 Cookie 无关的方案。
基于 OAuth 的认证方案
目前各大网站的开放式接口都是 SOA 架构,如果把这些开放式接口看作提供服务方(服务端),而把使用这些开放式接口的应用看作客户端,那么就可以产生这样一种和前后分离对应的关系:
所以,开放式接口广泛使用的 OAuth 方案用于前后分离是可行的,但在具体实施上却并不是那么容易。
尤其是在安全性上,由于前端是完全暴露在外的,与 OAuth 通常实施的环境(后端⇌服务端)相比,要注意的是首次认证不是使用已注册的 AppID 和 AppToken,而是使用用户名和密码。
基于 Token/JWT 的认证方案
虽然这个方案放在最后,但这个方案却是目前前后端分离最适合的方案。
基于 Token 的认证方案,各种讨论由来已久,而 JWT 是相对较为成熟,也得到多数人认可的一种。从 jwt.io 上可以找到各种技术栈的 JWT 实现,应用起来也比较方便。
总的来说,前后分离所带来的好处还是很明显的,但是具体实施的时候需要一个全新的思考方式,而不是基于原有一体化 Web 开发方式来进行思考。前后分离的开放方式将开发人员从复杂的技术组合中解放出来,大家都可以更专注于自己擅长的领域来进行开发。
但同时也对前后端团队的沟通交流提出了更高的要求,前后端团队必须要一同设计出相对稳定的 Web API 接口