前后端分离后,后端师傅们应该知道的一些基本前端知识

Posted anzhiruosu

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了前后端分离后,后端师傅们应该知道的一些基本前端知识相关的知识,希望对你有一定的参考价值。

 写下此文,是因为本人作为前端小白,经常遇到同样小白的后端,常常不得不三番五次科普一些前端的基础知识,特此做些总结,也方便有下次的话,直接拿出来给对方看。

 

1. 什么是ajax

        对于网络请求分类的维度有很多种,有一种就是这个请求发送出去是否需要刷新页面。比如form表单,比如直接从浏览器地址栏输入地址请求,这样的请求都是伴随着页面刷新的。而ajax,全称异步js和xml,简单来说,就是前端向后端发送请求,无需刷新页面,这在注重用户体验的前端领域,是极为宝贵的。不过有利就有弊,ajax很方便,但也有很多限制。

        对于ajax,后端并不需要了解多么深入,只需要知道有这么一回事,同时清楚,现在前后端交互,尤其是在前后端分离的情况下,ajax是使用最普遍的。

 

2. 跨域

      ajax有很多限制,在前后端分离之后,首当其中的就是跨域问题。在以前的诸如SSH框架下搭建的项目,因为前后端都在一起,是较少见跨域这种情况的,因此对于跨域的不了解,是后端小白们比较常见的问题。

      一个网络请求,url格式通常是:protocol://ip:port 。所谓跨域,就是当前页面的访问地址(也就是显示在浏览器地址栏里的url)和ajax请求的后端地址在protocol,ip,port三项中至少有一项不一样。

     如果出现了跨域ajax请求,因为浏览器的同源策略限制,如果不做任何处理,那么请求是不能成功的。对于跨域访问的解决方案有很多,比如jsonp,代理等方式,不过常用的还是CORS。

     使用CORS方案,后端要做的就是在请求响应头里添加‘Access-Control-Allow-Origin‘头,其值表示允许访问的源地址。常用的策略是获取request里的origin值,然后验证白名单(或黑名单),通过则将origin值赋给‘Access-Control-Allow-Origin‘响应头。测试的话,也可以设为*,表示允许来自任何源的跨域请求。

 

3. OPTIONS请求

      OPTIONS请求即预检请求,当一个请求不是简单请求时,浏览器会先发送一个预检请求,来确认是否能够请求成功,当能请求成功后,才会发送“真正”的请求。

      当使用跨域ajax的时候,因为会设置各种请求头信息,这样的请求就不是简单请求,这时就会出现预检请求的情况,在后端看来就会发现明明前端只请求了一次,却收到两次请求的情况,如果处理不当,就会出错。PS:有些框架可能会默认处理OPTIONS请求。

 

4.重定向

      在那个后端兼职的前端的古老年代,很多逻辑都是后端帮前端来做的,因此常常一言不合就302重定向。

      现在,后端师傅们,你们必须知道一点,不要试图操作前端了,你们唯一能做的就是告诉前端,你们想要做什么,至于帮不帮你做,得由我们前端说了算。

      当然,这么说并不是我们前端傲娇,而是ajax是不允许302重定向的。这个问题比较常见的是一些老项目,要采用前后端进行重构,后端则还是原来那一套,这时就会出现各种返回302的情况。

      比如本人就遇到多次这样的问题。我们公司的登录认证是采用sso形式的,很多老项目都是当请求来时,验证cookie,不通过,直接上302跳SSO服务。而这样的代码一般都是通用的,我们的小白后端或者是直接继承了前辈的项目,或者是复制的以前的项目代码而不知这个隐蔽的情况。当我试图请求不成功,发现302后,我跟他说不能重定向,他一脸懵逼的摇头,我没重定向啊(有的还会问什么是重定向,这种情况我只能甩他一个百度百科)。直到我看到响应头里的Location包含着sso等字样,我不得不长叹一口气,告诉他认证那块呢,同志!

 

结语

      讲道理,应该还有很多,只是今天暂时只遇到了这么些,以后想起了再补充吧。

      写完之后,发现有不少吐槽我们后端同学的地方,突然觉得背离了初衷,貌似不方便直接拿出来给他们看啊。

以上是关于前后端分离后,后端师傅们应该知道的一些基本前端知识的主要内容,如果未能解决你的问题,请参考以下文章

不懂前后端分离?这篇就够

jQuery如何实现类似JSTL的功能进行前后端分离?

Node前后端分离基本概括

WebAPI 实现前后端分离

WebAPI 实现前后端分离

WebAPI 实现前后端分离