随着Web技术的发展，现在各种框架，前端的，后端的，数不胜数。全栈工程师的压力越来越大。
现在的前端的框架，既可以做各种Web，又可以做各种APP，前端框架更新换代越来越快，越来越多。
传统的模式
前端和后端进行调试，修改都非常麻烦。往往前端配合后端很痛苦，后端也嫌前端麻烦。
（无解，能动手解决的事，尽量别动嘴。办公室应该常备一些，绷带，止血条，速效救心丸等药品。为了阻止事态升级，办公室要加强刀具管制条例。）
前后端分离
前端根据事先约定好的文档，可以自己摸拟数据，然后开发，测试，调试UI，发布到线上时把API接口改成线上API接口，即可完事。
前端日后增加新功能，修改UI，自己修改，自己编译更新自己UI站点，发布线上只要调上线上API接口即可。并不需要麻烦到后端。两者工作进行分离。
后端需要跟前端商量好接口，写好接口文档，在接口功能上相互沟通（其实相当于需求相互沟通），一旦接口文档订好之后，只需按事先约定实现API接口即口。把项目编译好发布到线上服务器。即可完事。
后端实现WebApi接口，还可以面对各种调用，如PC端web，手机APP，或者其它设备。一个接口多种调用，实现代码去重。
工作模式分析
对前端和后端进行分离。各司其职，各自在自己的领域集中精力研究。更能有效的加深技术深度。
前后端分离的模式，你需要N名前端工程师和N名后端工程师。
首先我们要约定一些返回基本的格式，比如用XML，还是JSON。结果大多数前端都是喜欢JSON，因为JS天生就支持JSON。
我贴出一些示例代码：
{ "ResultCode": 1300, "Message":"权限不足", "Data":null, }
{ "ResultCode": 1600, "Message":"逻辑异常", "Data":null, "DetailError":{ "ErrCode":1601001, "ErrMsg":"金额必须大于>0" } }
返回参数说明
参数名
类型
是否必有
说明
ResultCode
int
是
返回码
Message
string
是
结果说明
DetailError
josn
否
具体错误
Data
josn
否
数据
ResultCode
ResultCode
说明
1000
成功
1100
服务器异常
1200
身份验证异常
1300
权限不足
1400
传递参数验证不通过
1500
版本异常
1600
业务逻辑异常
1700
系统成升级中
1800
该接口己弃用
具体异常
这是一个有点争议的地方，有很多业务逻辑异常，出于对用户的友好提示。一些生涩难懂的错误提示，直接给到用户，用户一脸懵逼。但是后端却不能修改成友好提示，这样不方便调试，寻找问题原因。
一般来讲，前端可以自动修改友好提示给用户。
如果后端返回字符串，前端写死在代码中，万一，某一天后端认为这个描述更符合场景，修改的字符串。敌军还有30秒到达战场。
建议：尽量使用异常代码，大家可以看到上面贴出例子，就使用的异常代码。每种异常都有唯一编号，描述可以更改。但是编号不变。
用户异常（1601000）
说明
1601001
账号/密码错误
1601002
账号被冰冻
1601003
原密码不对
版本控制
每个API都有一个版本，其实也是就针对APP，如果是WEB端的，都是直接升级的因为B/S结构本身就是存在升级方便的优势，只需要把服务端更新就可以了。
版本控制一般用两种方式
第一种：URL不变，版本写在HTTP标头内面。
第二种：版本写在URL上面。
本人推荐第二种，比较直接方便了解。示例：
版本号 当前版本号：v1
API风格
现在流行的api风格比较多，最出名的就是restful风格。