前端处理过程中常常发现接口定义不符合用户操作流程，AJAX 异步请求过多等问题
采用基于 Token 的认证就意味着后端的认证部分需要重写
从后端的角度来看，重点关注的是数据完整、有效、安全。矛盾在于双方关注点不同，信息不对称，还各有私心
就形式上来说，Web API 可以定义成 REST，也可以是 RPC，只要前后端商议确定下来就行。更重要的是在输入参数和输出结果上，最好一开始就有相对固定的定义，这往往取决于前端架构或采用的 UI 框架。
常见请求参数的数据形式有如下一些：
键值对，用于 URL 中的 QueryString 或者 POST 等方法的 Payload
XML/JSON/...，通常用于 POST 等方法的 Payload，也可以使用 multipart 传递
ROUTE，由后端路由解析 URL 取得，在 RESTful 中常用
而服务器响应的数据形式就五花八门各式各样了，通常一个完整的响应至少需要包含状态码、消息、数据三个部分的内容，其中
状态码，HTTP 状态码或响应数据中特定的状态属性
消息，通常是放在响应内容中，作为数据的一部分
数据，根据接口协议，可能是各种格式，当前最流行的是 JSON
我们在实践中使用 JSON 形式，最初定义了这样一种形式
{
"code": "number",
"message": "string",
"data": "any"
}
code 主要用于指导前端进行一些特殊的操作，比如 0 表示 API 调用成功，非0 表示调用失败，其中 1 表示需要登录、2 表示未获取授权……对于这个定义，前端拿到响应之后，就可以在应用框架层进行一些常规处理，比如当 code 为 1 的时候，弹出登录窗口请用户在当前页面登录，而当 code 为 2 的时候，则弹出消息提示并后附链接引导用户获取授权。
http://blog.51cto.com/jamesfancy/2061675
前后分离模型之封装 Api 调用
一开始这样做并没有什么问题，直到前端框架换用了 jQuery EasyUI。以 EasyUI 为例的好多 UI 库都支持为组件配置数据 URL，它会自动通过 AJAX 来获取数据，但对数据结构有要求。如果仍然采用之前设计的响应结构，就需要为组件定义数据过滤器（filter）来处理响应结果，这样做写 filter 以及为组件声明 filter 的工作量也是不小的。为了减少这部分工作量我们决定改一改接口。
新的接口是一种可变结构，正常情况下返回 UI 需要的数据结构，出错的情况则响应一个类型于原定结构的数据结构：
{
"error": {
"identity": "special identity string",
"code": "number",
"message": "string",
"data": "any"
}
}
对于新响应数据结构，前端框架只需要判断一下是否存在 error 属性，如果存在，检查其 identity 属性是否为指定的特殊值（比如某个特定的 GUID），然后再使用其 code 和 message 属性处理错误。这个错误判断过程略为复杂一些，但可以由前端应用框架统一处理。
如果使用 RESTful 风格的接口，部分状态码可以用 HTTP 状态码代替，比如 401 表示需要登录，403 就可以表示没有获得授权，500 表示程序处理过程中发生错误。当然，虽然 HTTP 状态码与 RESTful 风格更配，但是非 RESTful 风格也可以使用 HTTP 状态码来代替 error.code。
用户认证
认证方案很多，比如 Cookie/Session 在某些环境下仍然可行、也可以使用基于 Token 和 OAuth 或者 JWT，甚至是自己实现基于 Token 的认证方式。
基于 Cookie/Session 的认证方案
采用传统的 Cookie/Session 认证方案并非不可行，只不过有一些限制。如果前端部分和后端部分同源，比如页面发布在 http://domain.name/，而 Web API 发布在 http://domain.name/api/，这种情况下，原来的一体式 Web 方案所采用的 Cookie/Session 方案可以直接迁移过来，毫无压力。但是如果前面发布和 API 发布不同源，这种方法处理起来就复杂了。
然后一般前后端分离的开发方式，不管是开发阶段还是发布阶段，不同源的可能性占绝大比例，所以认证方案通常会使用与 Cookie 无关的方案。
基于 OAuth 的认证方案
目前各大网站的开放式接口都是 SOA 架构，如果把这些开放式接口看作提供服务方（服务端），而把使用这些开放式接口的应用看作客户端，那么就可以产生这样一种和前后分离对应的关系：
前端 ⇌ 客户端
⇣
基于 OAuth 的认证）
⇡
后端 ⇌ 服务端
所以，开放式接口广泛使用的 OAuth 方案用于前后分离是可行的，但在具体实施上却并不是那么容易。尤其是在安全性上，由于前端是完全暴露在外的，与 OAuth 通常实施的环境（后端⇌服务端）相比，要注意的是首次认证不是使用已注册的 AppID 和 AppToken，而是使用用户名和密码。
基于 Token/JWT 的认证方案
虽然这个方案放在最后，但这个方案却是目前前后端分离最适合的方案。基于 Token 的认证方案，各种讨论由来已久，而 JWT 是相对较为成熟，也得到多数人认可的一种。从 jwt.io 上可以找到各种技术栈的 JWT 实现，应用起来也比较方便。
话虽如此，JWT 方案和以前使用的 Cookie/Session 在处理上还是有较大的差别，需要一定的学习成本。有人担心 JWT 的数据量太大。这确实是一个问题，但是硬件并不贵，4G 也开始进入不限流量阶段，一般应用中不用太在意这个问题。
前后分离的测试
前后分离之后，前端的测试将以用户体验测试和集成测试为主，而后端则主要是进行单元测试和 Web API 接口测试。与一体化的 Web 应用相比，多了一层接口测试，这一层测试可以完全自动化，一旦完成测试开发，就能在很大程度上控制住业务处理和数据错误。这样一来，集成测试的工作量会相对单一也容易得多。
前端测试的工作相对来说减轻不了多少，前后分离之后的前端部分承担了原来的集成测试工作。但是在假设 Web API 正确的情况下进行集成测试，工作量是可以减轻不少的，用例可以只关注前端体验性的问题，比如呈现是否正确，跳转是否正确，用户的操作步骤是否符合要求以及提示信息是否准确等等。
对于用户输入有效性验证这部分工作在项目时间紧迫的情况下甚至都可以完全抛给 Web API 去处理。不管是否前后端分离，Web 开发中都有一个共识：永远不要相信前端！既然后端必须保证数据的安全性和有效性，那么前端省略这一步骤并不会对后端造成什么实质性的威胁，最多只是用户体验差一点。但是，如果前后端都要做数据有效性验证，那一定要严格按照文档来进行，不然很容易出现前后端数据验证不一致的情况（这不是前后分离的问题，一体化架构同样存在这个问题）。
小结
总的来说，前后分离所带来的好处还是很明显的。但是具体实施的时候需要一个全新的思考方式，而不是基于原有一体化 Web 开发方式来进行思考。前后分离的开放方式将开发人员从复杂的技术组合中解放出来，大家都可以更专注于自己擅长的领域来进行开发，但同时也对前后端团队的沟通交流提出了更高的要求，前后端团队必须要一同设计出相对稳定的 Web API 接口（这部分工作其实不管是否前后端分离都是少不了的，只是前后分离的架构对此要求更高，更明确地要求接口不只存在于人的记忆中，更要文档化、持久化）。
2017-07
本文转自 liqius 51CTO博客，原文链接：http://blog.51cto.com/szgb17/2063541，如需转载请自行联系原作者
