这篇文章主要讲解了“怎么规范web前后台请求参数校验”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“怎么规范web前后台请求参数校验”吧!
1. 什么时候我们会前、后端校验?
正常情况下,前后端对于请求的参数都需要校验的,这能提高应用程序的稳定性、可维护性,而对于前后台如果能将这种不可缺少校验规则汇总并制定一套规范,在每一个应用程序中都使用这种规范,能给带来不少好处。那在哪些情况下适合使用前、后端校验了:
应用程序业务单一、后期维护少、不涉及敏感信息,如:公司内部OA系统,这种系统可以直接使用前端校验,而这里的前端参数校验可以使用:H5表单校验或者封装常用校验JS文件。
应用程序业务单一、后期维护少;如:支付系统,由于支付系统可能会有其他公司对接平台的接口,所有这种前端校验就交给其他公司了,我们只需要做好后端校验就行。
业务复杂、后期维护多、安全可用性要求高,如:电商项目的维护,这种方式要同时使用前后端校验,前端校验的目的是为了把更多的错误请求都在浏览器层面就已经拦截处理,不会消耗服务端的内存和线程数,可以提供性能;对于还要进行后端校验是为了提高系统的稳定性,不要动不动就500,还能防止一些人恶意攻击网站等等。
2. 前端请求参数校验
常用的方式有这些:
自己封装一个通用校验JS文件,统一校验方式(使用与JS发送请求)
H5标签属性检验方式(适用于web form表单提交)
第三方JS自己封装的校验方法,这里对前端的建议尽量统一起来、规范起来。
3. 后端请求参数校验
常用的方式有这些:
不校验,我对比了之前开发的一些小系统(外包)对于后端参数基本没有,这种方式的确可以做到后端开发快,所有的校验都交给前端做,但对于前端不友好,如:由于前端少传递一个参数,导致后端程序报错,而后端又没有提供详细的报错信息,这给前端对接带来了问题,前端不知道自己错在哪里,这个时候可能还的和后端人员进行沟通,后端看看Log再告诉前端,这种方式对于前端对接不友好并且效率低。
封装自己的校验工具类进行检验,这种方式的确能做到后端交易,但如果需要校验的参数比较多对程序是不友好的,如:
使用@RequestParam注解完成简单非空校验,这种虽然可以检验,但如果没有传此字段会抛出异常,这里需要通过全局异常捕获统一处理。
@RequestParam(value = "mobile", required = true) String mobile
使用Interceptor、Filter、Aop.. 做公共部分的业务做统一的校验处理,如:Token检验,权限校验..
如果需要校验的参数比较多,校验方式和业务代码混合在一块不方便于代码的维护,可以使用hibernate-validator来做分组校验。
虽然到这里通过hibernate-validator来做分组校验就可以解决所有方式的参数校验:
分组管理不同接口参数校验差异
可自定义注解校验复杂情况
但也存在问题,后端校验的确做到了,但如果要将这些参数校验都编写到接口文档中,这个时候我们还需要先找接口、找到分组、找到dto下分组对应的所有参数校验,增加参数校验规则还得重新修改接口文档等等。
感谢各位的阅读,以上就是“怎么规范web前后台请求参数校验”的内容了,经过本文的学习后,相信大家对怎么规范web前后台请求参数校验这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是亿速云,小编将为大家推送更多相关知识点的文章,欢迎关注!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。