WebAPI 实现前后端分离

随着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上面。

本人推荐第二种,比较直接方便了解。示例:

http://www.xxx.com/版本号

当前版本号:v1

http://www.baidu.com/v1/UserSecurity/Login

API风格

现在流行的api风格比较多,最出名的就是restful风格。

按本人的经验,完全走restful风格是很困难的,可能也是水平问题,在团队内面也要考虑到其它成员的水平问题。我们目前API风格还是保留以前风格。

示例,V*代表版本号

http://xx.com/V*/UserSecurity/SignOut

HTTP谓词

使用 Post 方法在服务器上创建/修改/删除资源

使用 Get 方法从服务器检索某个资源或者资源集合

基本命名规则

使用骆驼式命名法-大驼峰法

跨域处理

前端站点和后端API布署到不同的站点,就会产生跨域问题。

什么是同源策略?

同源是域名,协议,端口相同。也就是说如果不同,则是非同源。

同源策略是浏览器的一基本的安全功能,非同源访问,浏览器会进行拒绝。

HMTL上面的SRC地址,你可以指定任何URL,表单提交,你可以提交到任何URL。

但是,你如果使用AJAX技术,就会受到同源策略的影响,拒绝提交。

现代浏览器几乎都支持跨域资源请求的一种方式。这种技术叫CORS(跨域资源共享)

CORS跨域分两种

第一种,简单跨域。

第二种,复杂跨域。

解决方案:HTTP输出标头增加如何节点

注意有前端框架版本,对安全要求较高,不能使用通配符*,要指定跨域域名。

Access-Control-Allow-Origin:*

下面节点可填,可不填,根据实际情况,自行决定。


1

2

3

Access-Control-Allow-Methods:GET,POST,OPTIONS

Access-Control-Allow-Credentials:true

Access-Control-Allow-Headers:根据请求头的内容,填写

  

注意:复杂跨域比要简单跨域麻烦,更花费性能。因为复杂跨域在请求之前会先发一个options预请求,根据响应判断服务器是否支持跨域。也就是说,实际上请求了两次。

Cookies作用域

不同的站点,如何通用Cookies?

一般情况只需把cookies作用域设置顶级域名,浏览器会自动把cookies在访问子域名的时候捎上去。

示例,访问二级域名时候,cookies默认会被传送过去。

顶级域名:baidul.com
cookies作用域:.baidu.com
二级域名:
www.baidu.com
api.baidu.com

示例

下面贴一些示例文档,其它的就不多讲啦

基本上,WebApi前后端分离的细节和注意点,都记录下来,还有更多的细节,需要读者在开发过程自己去寻找答案。随笔完毕!

原文地址:https://www.cnblogs.com/itrena/p/8305857.html

时间: 2024-11-02 22:00:06

WebAPI 实现前后端分离的相关文章

WebAPI 实现前后端分离的示例

转自:http://www.aspku.com/kaifa/net/298780.html 随着Web技术的发展,现在各种框架,前端的,后端的,数不胜数.全栈工程师的压力越来越大. 现在的前端的框架,既可以做各种Web,又可以做各种APP,前端框架更新换代越来越快,越来越多. 传统的模式 前端和后端进行调试,修改都非常麻烦.往往前端配合后端很痛苦,后端也嫌前端麻烦. (无解,能动手解决的事,尽量别动嘴.办公室应该常备一些,绷带,止血条,速效救心丸等药品.为了阻止事态升级,办公室要加强刀具管制条例

ASP.NET WebApi+Vue前后端分离之允许启用跨域请求

前言: 这段时间接手了一个新需求,将一个ASP.NET MVC项目改成前后端分离项目.前端使用Vue,后端则是使用ASP.NET WebApi.在搭建完成前后端框架后,进行接口测试时发现了一个前后端分离普遍存在的问题跨域(CORS)请求问题.因此就有了这篇文章如何启用ASP.NET WebApi 中的 CORS 支持. 一.解决Vue报错:OPTIONS 405 Method Not Allowed问题: 错误重现: index.umd.min.js:1 OPTIONS http://local

分享一个前后端分离方案源码-前端angularjs+requirejs+dhtmlx 后端asp.net webapi

一.前言 半年前左右折腾了一个前后端分离的架子,这几天才想起来翻出来分享给大家.关于前后端分离这个话题大家也谈了很久了,希望我这个实践能对大家有点点帮助,演示和源码都贴在后面. 二.技术架构 这两年angularjs和reactjs算是比较火的项目了,而我选择angularjs并不是因为它火,而是因它的模块化.双向数据绑定.注入.指令等都是非常适合架构较复杂的前端应用,而且文档是相当的全,碰到问题基本上可以在网上都找到答案.所以前端基本思路就以angularjs为主.代码模块化,通过requir

【开源.NET】 分享一个前后端分离的轻量级内容管理框架

开发框架要考虑的面太多了:安全.稳定.性能.效率.扩展.整洁,还要经得起实践的考验,从零开发一个可用的框架,是很耗时费神的工作.网上很多开源的框架,为何还要自己开发?我是基于以下两点: 没找到合适的:安全.稳定.简单.易用.高效.免费: 想成为架构师: 于是就自己动手,参考网上开源的项目和借鉴网友的设计思路(特别是萧秦系列博文),结合自己的实践,开发了一个简单.易用.高效的的框架,虽然不完善,但也能解决现实中的问题.不过随着见识增广,发现没负责过千万级别的项目难以成为架构师,也不可能开发出一个完

[开源] angularjs + Asp.net 前后端分离解决方案

本文版权归 博客园 萧秦 所有,此处为技术收藏,如有再转,请于篇头明显位置标明原创作者及出处,以示尊重! 作者:萧秦 原文:http://www.cnblogs.com/xqin/p/4862849.html 一.前言 半年前左右折腾了一个前后端分离的架子,这几天才想起来翻出来分享给大家.关于前后端分离这个话题大家也谈了很久了,希望我这个实践能对大家有点点帮助,演示和源码都贴在后面. 二.技术架构 这两年angularjs和reactjs算是比较火的项目了,而我选择angularjs并不是因为它

为什么前后端分离了,你比从前更痛苦?

? 你有没有遇到过: 前端代码刚写完,后端的接口又变了. 接口文档永远都是不对的. 测试工作永远只能临近上线才能开始. 为什么前后端分离了,你比从前更痛苦? 前后端分离早已经不是新闻,当真正分离之后确遇到了更多问题.要想解决现在的痛,就要知道痛的原因: 为什么接口会频繁变动? 设计之初没有想好. 这需要提高需求的理解能力和接口设计能力. 变动的成本较低. 德国有句谚语:"朝汤里吐口水." 只有这样,才能让人们放弃那碗汤,停止不合理的行为.前后端同学坐在一起工作的时候效率会有提升,当后端

前后端分离的一些尝试

背景 目前使用SpringMVC框架进行开发,用户访问controller的url,controller收到页面数据后分发给serverice做处理,处理完后在controller中根据页面所需要的数据进行整合,最后将打包好的信息发给指定的页面. 根据上图我们可以看到,数据的整合是在controller层上做处理的,而页面则对整合的数据进行对应的显示,两部分需要对应好,如果增加一个对应的控件涉及到后台的数据,则页面和后端都需要修改,即使该空间的service已经存在,也需要在controller

利用grunt-contrib-connect和grunt-connect-proxy搭建前后端分离的开发环境

前后端分离这个词一点都不新鲜,完全的前后端分离在岗位协作方面,前端不写任何后台,后台不写任何页面,双方通过接口传递数据完成软件的各个功能实现.此种情况下,前后端的项目都独立开发和独立部署,在开发期间有2个问题不可避免:第一是前端调用后台接口时的跨域问题(因为前后端分开部署):第二是前端脱离后台服务后无法独立运行.本文总结最近一个项目的工作经验,介绍利用grunt-contrib-connect和grunt-connect-proxy搭建前后端分离的开发环境的实践过程,希望能对你有所帮助. 注:

前后端分离的方法

网站前后端分离的方法 如何进行前后端分离: http://blog.csdn.net/github_26672553/article/details/51864112 https://segmentfault.com/q/1010000004494530 解释了前后端的分离方法 http://www.csdn.net/article/2015-10-25/2826033