Web前后端分离的考虑

1. 先从历史说起

第一个Web程序也就是test.html，里面一句

Hello World

，然后把文件往服务器一扔，开个端口给它，这个小网站就发布完成了。

然后换动态网页登场，什么.jsp啊.asp啊.cshtml啊给人感觉非常酷炫。有了这些页面还不够，还要把视图渲染跟业务数据处理给分离开来，那就加上servlet啊controller.cs啊并分离出Bll层Dao层来。这些全是服务器代码的升级，而呈献给用户的页面却始终在一个视图文件里发挥，用jQuery来做一些点击特效再加上异步请求就算是酷炫到不行了。

现在的Web应用比较流行的是设计成单页应用(SPA)，页面无跳转，靠的是前端路由框架来操作DOM来实现接近原生应用的交互体验。开发SPA的话，动态网页也成为过去式了，完全可以回到最原始的index.html作为入口，搭配脚本资源文件，使用WebApi与服务器进行业务与数据交互。页面的呈现不再是由服务器解析动态页面模板成实际html发送到浏览器，而是浏览器从index.html进入后由脚本生成整个客户端应用。由于是Web应用，仍需将客户端资源部署成一个网站，不过严格上讲已经只是个分发入口文件与脚本的网站，后续的网络请求都是与专门的WebApi交互，这个WebApi可能同时还服务于其他原生项目、桌面应用等，从而实现服务端与客户端的彻底分离。

前后端的交互方式

2.分离需要解决的问题

1). 跨域

强行将WebApi与前端应用部署在同一个域中也不是不行，但是这也就失去了分离的一小部分意义，跨域要实现的主要是对WebApi响应头的处理，以及将http请求升级为https。

2). 确保客户端可靠

客户端分离成独立项目后，WebApi应当将任何请求来源都视为不可信，毕竟客户端现在脱离了出去，很容易被伪造，也没有完全防止被伪造的方法，要做的应该是加上完善的授权认证体系，增加伪造客户端的门槛。

参照微信开发中我们自己的网站与微信服务器的Api交互。我们申请成为微信开发者后会得到AppId与AppSecret，微信服务器用这两个东西来确认我们得身份，在交互时通过这两个数据获取交互凭证(AccessToken)，然后才能使用凭证进行具体的Api交互，凭证存在过期时间，过期后需要重新获取。

回到自己的网站上，前端想要与WebApi交互，也就需要一个WebApi提供的AppId与AppSecret，客户端需要保存好这两个数据，并加以保护，在进行WebApi请求时也通过换取accesstoken的方式进行认证即可。同时还可以增加签名概念，将请求字段通过特定的加密算法生成签名，WebApi收到请求后也进行签名验证，用来排除恶意、超时、未知来源的请求。

先向WebApi请求凭证，再用凭证进行具体请求

3). 客户端登录保持

传统Web网站的登录状态相对比较容易管理，因为服务器可以操作Cookie以及Session来控制登录数据，但Web分离成客户端后，WebApi显然不能再操作Cookie或是Session了，所以客户端必须进行存储登录数据，用来代替Cookie，并在需要身份认证的请求中带上身份信息，此过程很有必要进行加密，https就派上用场了(传统的网站交互未使用https情况下安全性也是相当低，好在不需要跨域)。

4). 第三方服务接入

再考虑一种情况，现有一个WebApp客户端网站，来与自己的WebApi交互完成业务请求，这时需要加入第三方授权登录模块(这里用微信登录举例)，来简化用户的登录操作，这就涉及到了微信服务器、客户端、WebApi三端的交互，这也是需要权衡的，哪些事必须由客户端完成，哪些事必须在WebApi中完成。

3.分离的优势

最明显的优势是可伸缩性，将服务器逻辑浓缩在WebApi中提供给客户端，自然就支持多个客户端，假设有一个WebApi服务了一百个客户端网站，即使WebApi忙于处理太多请求，客户端也至少能把等待页面呈现给用户，业务扩大时，可以很轻松的扩展WebApi或是客户端的负载均衡能力，两端互不影响。

还有就是WebApi不仅能服务Web网站，还可以将其打造成跨平台App，由于客户端是分离出来的，服务器的作用极微弱，迁移到App的WebView上会相对简单。