WebFrom、MVC、前后端分离(后端 Restful API,前端使用前端框架,例如Angular、React、Vue)。
在前后端不分离的开发模式中,前端页面看到的效果都是由后端控制,由后端渲染页面或重定向,也就是后端需要控制前端的展示,前端与后端的耦合度很高。
这种开发模式比较适合纯网页应用,但是当后端对接App时,App可能并不需要后端返回一个HTML网页,而仅仅是数据本身,所以后端原本返回网页的接口不在适用于前端App应用,为了对接App,后端还需要在开发一套接口。
术业有专攻,前端做前端的,后端做后端的。
服务器一分为二,前后端分别部署,静态资源放在前端服务器,业务代码放在后端服务器。前端服务器需要接收HTTP请求。前端服务器需要进行视图解析(可以使用Vue.js、Angular)。前端服务器需要处理路由(也就是页面之间的跳转)。后端服务器只负责返回数据给前端。
其实这还是由前后端分离后的优势决定的:术业有专攻,前端做前端的,后端做后端的。服务器一分为二,前后端分别部署,静态资源放在前端服务器,业务代码放在后端服务器。前端服务器需要接收HTTP请求。前端服务器需要进行视图解析(可以使用Vue.js、Angular)。前端服务器需要处理路由(也就是页面之间的跳转)。后端服务器只负责返回数据给前端。
因为同源策略。跨域问题来源于JavaScript的同源策略,即只有协议+主机名+端口号(如存在)相同,则允许相互访问。也就是说,JavaScript只能访问和操作自己域下的资源,不能访问和操作其它与下面的资源。跨域问题是针对JS和Ajax的,HTML本身没有跨域问题,比如a标签,script标签,甚至form标签(可以直接跨域发送数据并接收数据)等。
第一种:服务器执行请求过来以后,允许你跨域;其实服务器设置响应头:response.setHeader("Access-Control-Allow-Origin", "*")。
第二种:jsonp的方式。注意:这种方式只能发送get请求。就算指定为post,最后发送的还是get,且跟上面方式一样,也需要服务器的配合支持。jsonp发送的并不是ajax请求;利用动态创建一个script标签,因为script标签是没有同源策略限制的,是可以跨域的; 把这个script标签的src指向我们请求的服务端地址,这个地址会携带一个参数:callback ,一个回调函数,服务端会把数据通过这个回调函数返回给客户端,但是客户端没有这个函数怎么接收呢?所以在发送请求之前,要在全局(window)注册这样一个方法,利用这个方法,来获得数据; 这个回调函数名需要跟服务端约定好,是一致的。例如:
<script> //指定的回调函数 function showData (result) { var data = JSON.stringify(result); //json对象转成字符串 $("#text").val(data); } $(document).ready(function () { $("#btn").click(function () { //向头部输入一个脚本,该脚本发起一个跨域请求 $("head").append("<script src=‘http://localhost:9090/student?callback=showData‘><\/script>"); }); }); </script>
第三种:代理服务器,跨域问题是浏览器的同源策略限制,服务器之间是没有的,那我们先把请求给我们的代理服务器,再让我们的代理服务器去调用这个接口,在发送给前端就可以了。
第四种:在后端代码里面设置。比如ASP.NET Web API或者ASP.NET Core Web API里面都可以设置。
现在常用的是请求加上用户名和密码实时验证、Token验证;
用户名和密码实时验证:client发生username和password到server。server验证成功以后。写cookie到client,然后返回OK的JSON,其中cookie的key要存储在Redis中,value就是用户信息。并且要设置key的超时时间,例如10分钟。client收到ok后, 进行相应的业务操作, 以后每次请求server都会自动带上cookie, 不用你写代码;server端的filter(你肯定用filter来实现)中会每次验证传过来的cookie的key在redis中是否存在, 有就代表登录成功过可以操作, 没有就返回错误标识。
注意: 在登录成功后, 每次调用服务器接口时候, 都要为redis的key进行续期,如60分钟。
当redis的key超过60分钟, 自己会删除这个key, 那么再次请求server时, 就会收到需要登录的返回值。当用户主动退出系统的时候, 也要在server中删除redis的key。
Token方式。
token一般用来做显示的身份验证, 比如手机验证码之类的, 这些都需要手动传递token到后台。在client点击验证码,server发送验证码,返回给client一个token,在client对验证码进行验证,传递token + 验证码到server,
server对token+验证码进行验证。
Ajax优势:
最大的一点是页面无刷新,在页面内与服务器通信,给用户的体验非常好。
使用异步方式与服务器通信,不需要打断用户的操作,具有更加迅速的响应能力。
可以把以前一些服务器负担的工作转嫁到客户端,利用客户端闲置的能力来处理,减轻服务器和带宽的负担,节约空间和宽带租用成本。并且减轻服务器的负担,ajax的原则是“按需取数据”,可以最大程度的减少冗余请求,和响应对服务器造成的负担。
基于标准化的并被广泛支持的技术,不需要下载插件或者小程序。
Ajax局限:
ajax干掉了back按钮,即对浏览器后退机制的破坏。后退按钮是一个标准的web站点的重要功能,但是它没法和js进行很好的合作。这是ajax所带来的一个比较严重的问题,因为用户往往是希望能够通过后退来取消前一次操作的。那么对于这个问题有没有办法?答案是肯定的,用过Gmail的知道,Gmail下面采用的ajax技术解决了这个问题,在Gmail下面是可以后退的,但是,它也并不能改变ajax的机制,它只是采用的一个比较笨但是有效的办法,即用户单击后退按钮访问历史记录时,通过创建或使用一个隐藏的IFRAME来重现页面上的变更。(例如,当用户在Google Maps中单击后退时,它在一个隐藏的IFRAME中进行搜索,然后将搜索结果反映到Ajax元素上,以便将应用程序状态恢复到当时的状态。)。但是,虽然说这个问题是可以解决的,但是它所带来的开发成本是非常高的,和ajax框架所要求的快速开发是相背离的。这是ajax所带来的一个非常严重的问题。
对搜索引擎的支持比较弱。
破坏了程序的异常机制。至少从目前看来,像ajax.dll,ajaxpro.dll这些ajax框架是会破坏程序的异常机制的。关于这个问题,我曾经在开发过程中遇到过,但是查了一下网上几乎没有相关的介绍。后来我自己做了一次试验,分别采用ajax和传统的form提交的模式来删除一条数据……给我们的调试带来了很大的困难。
另外,像其他方面的一些问题,比如说违背了url和资源定位的初衷。例如,我给你一个url地址,如果采用了ajax技术,也许你在该url地址下面看到的和我在这个url地址下看到的内容是不同的。这个和资源定位的初衷是相背离的。
一些手持设备(如手机、PDA等)现在还不能很好的支持ajax,比如说我们在手机的浏览器上打开采用ajax技术的网站时,它目前是不支持的,当然,这个问题和我们没太多关系。
区别:axios是通过promise实现对ajax技术的一种封装,就像jQuery实现ajax封装一样。简单来说: ajax技术实现了网页的局部数据刷新,axios实现了对ajax的封装。axios是ajax ajax不止axios。
Ajax:本身是针对MVC的编程,不符合现在前端MVVM的浪潮。基于原生的XHR开发,XHR本身的架构不清晰,已经有了fetch的替代方案。JQuery整个项目太大,单纯使用ajax却要引入整个JQuery非常的不合理(采取个性化打包的方案又不能享受CDN服务)。
axios:从 node.js 创建 http 请求。支持 Promise API。客户端支持防止CSRF。提供了一些并发请求的接口(重要,方便了很多的操作)。
建议在开发的时候使用谷歌浏览器,调试测试方便!可以直接查看浏览器network,确定是某一个接口报错!根据报错的状态码;查看异常事件,如果接口方有日志、直接查看日志;选择性调整;
可以直接通过浏览器Network查看到是那个接口在请求的时候耗时间,然后有针对性的优化接口;
vue和jquey对比 jQuery是使用选择器()选取DOM对象,对其进行赋值、取值、事件绑定等操作,其实和原生的HTML的区别只在于可以更方便的选取和操作DOM对象,而数据和界面是在一起的。比如需要获取label标签的内容:(“lable”).val();,它还是依赖DOM元素的值。 Vue则是通过Vue对象将数据和View完全分离开来了。对数据进行操作不再需要引用相应的DOM对象,可以说数据和View是分离的,他们通过Vue对象这个vm实现相互的绑定。这就是传说中的MVVM。
GET传递的参数只能带URL后面,文本格式QueryString,各浏览器一般有长度限制,一般认为是2083,如果有中文字符更短。提交到服务器端的数据量小。
POST可以传递application/x-www-form-urlencoded的类似QueryString、multipart/form-data的二进制报文格式(支持文件信息嵌入报文传输)、纯文本或二进制的body参数。提交到服务器端的数据量大。
Web Service:
WCF
Web API:
可以选择数据压缩;常见的数据压缩像gzip;
原文:https://www.cnblogs.com/dotnet261010/p/12310261.html