跟着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气势派头。