这期内容当中小编将会给大家带来有关使用WebAPI如何实现前后端分离,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。
<强>传统的模式强>
前端和后端进行调试,修改都非常麻烦。往往前端配合后端很痛苦,后端也嫌前端麻烦。
(无解,能动手解决的事,尽量别动嘴。办公室应该常备一些,绷带,止血条,速效救心丸等药品。为了阻止事态升级,办公室要加强刀具管制条例)。
<强>前后端分离强>
前端根据事先约定好的文档,可以自己摸拟数据,然后开发,测试,调试UI,发布到线上时把API接口改成线上API接口,即可完事。
前端日后增加新功能,修改UI,自己修改,自己编译更新自己UI站点,发布线上只要调上线上API接口即可。并不需要麻烦到后端。两者工作进行分离。
后端需要跟前端商量好接口,写好接口文档,在接口功能上相互沟通(其实相当于需求相互沟通),一旦接口文档订好之后,只需按事先约定实现API接口即口。把项目编译好发布到线上服务器。即可完事。
后端实现WebAPI接口,还可以面对各种调用,如PC端网络,手机应用程序,或者其它设备。一个接口多种调用,实现代码去重。
<强>工作模式分析强>
对前端和后端进行分离。各司其职,各自在自己的领域集中精力研究。更能有效的加深技术深度。
前后端分离的模式,你需要N名前端工程师和N名后端工程师。
首先我们要约定一些返回基本的格式,比如用XML,还是JSON。结果大多数前端都是喜欢JSON,因为JS天生就支持JSON。
<强>我贴出一些示例代码:强>
{ ,“ResultCode": 1300年, ,“Message":“权限不足“, ,“Data":空, 以前,}>{ ,“ResultCode": 1600年, ,“Message":“逻辑异常“, ,“Data":空, ,“DetailError": { ,“ErrCode": 1601001, ,“ErrMsg":“金额必须大于祝辞0“; ,} ,}<强>返回参数说明强>
参数名类型是否必有说明ResultCodeint是返回码Messagestring是结果说明DetailErrorjosn否具体错误Datajosn否数据<强> ResultCode 强>
ResultCode说1000年明成功1100服务器异常1200身份验证异常1300权限不足1400传递参数验证不通过1500版本异常1600业务逻辑异常1700系统成升级中1800年该接口己弃用<强>具体异常强>
这是一个有点争议的地方,有很多业务逻辑异常,出于对用户的友好提示。一些生涩难懂的错误提示,直接给到用户,用户一脸懵逼。但是后端却不能修改成友好提示,这样不方便调试,寻找问题原因。
一般来讲,前端可以自动修改友好提示给用户。
如果后端返回字符串,前端写死在代码中,万一,某一天后端认为这个描述更符合场景,修改的字符串。敌军还有30秒到达战场。
<强>建议:>强尽量使用异常代码,大家可以看到上面贴出例子,就使用的异常代码。每种异常都有唯一编号,描述可以更改。但是编号不变。
用户异常(1601000)说明1601001账号/密码错误1601002账号被冰冻1601003原密码不对<强>版本控制强>
每个API都有一个版本,其实也是就针对应用程序,如果是WEB端的,都是直接升级的因为B/S结构本身就是存在升级方便的优势,只需要把服务端更新就可以了。
<强>版本控制一般用两种方式强>
<强>第一种:强> URL不变,版本写在HTTP标头内面。
<强>第二种:>强版本写在URL上面。
本人推荐第二种,比较直接方便了解。示例:
http://www.xxx.com/版本号 当前版本号:v1 http://www.baidu.com/v1/UserSecurity/Login<>强API风格强>
现在流行的API风格比较多,最出名的就是宁静的风格。
按本人的经验,完全走restful风格是很困难的,可能也是水平问题,在团队内面也要考虑到其它成员的水平问题。我们目前API风格还是保留以前风格。
示例,V *代表版本号
http://xx.com/V */UserSecurity SignOut<强> <强> HTTP谓词强> 强>
使用发布方法在服务器上创建/修改/删除资源
使用得到方法从服务器检索某个资源或者资源集合
<>强基本命名规则强>
使用骆驼式命名法——大驼峰法
<强> <强>跨域处理强> 强>
前端站点和后端API布署到不同的站点,就会产生跨域问题。
什么是同源策略?
同源是域名,协议,端口相同。也就是说如果不同,则是非同源。
使用WebAPI如何实现前后端分离