怎么規(guī)范web前后臺請求參數(shù)校驗

這篇文章主要講解了“怎么規(guī)范web前后臺請求參數(shù)校驗”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“怎么規(guī)范web前后臺請求參數(shù)校驗”吧！

1. 什么時候我們會前、后端校驗？

正常情況下，前后端對于請求的參數(shù)都需要校驗的，這能提高應(yīng)用程序的穩(wěn)定性、可維護性，而對于前后臺如果能將這種不可缺少校驗規(guī)則匯總并制定一套規(guī)范，在每一個應(yīng)用程序中都使用這種規(guī)范，能給帶來不少好處。那在哪些情況下適合使用前、后端校驗了：

• 應(yīng)用程序業(yè)務(wù)單一、后期維護少、不涉及敏感信息，如：公司內(nèi)部OA系統(tǒng)，這種系統(tǒng)可以直接使用前端校驗，而這里的前端參數(shù)校驗可以使用：H5表單校驗或者封裝常用校驗JS文件。

• 應(yīng)用程序業(yè)務(wù)單一、后期維護少；如：支付系統(tǒng)，由于支付系統(tǒng)可能會有其他公司對接平臺的接口，所有這種前端校驗就交給其他公司了，我們只需要做好后端校驗就行。

• 業(yè)務(wù)復(fù)雜、后期維護多、安全可用性要求高，如：電商項目的維護，這種方式要同時使用前后端校驗，前端校驗的目的是為了把更多的錯誤請求都在瀏覽器層面就已經(jīng)攔截處理，不會消耗服務(wù)端的內(nèi)存和線程數(shù)，可以提供性能；對于還要進行后端校驗是為了提高系統(tǒng)的穩(wěn)定性，不要動不動就500，還能防止一些人惡意攻擊網(wǎng)站等等。

2. 前端請求參數(shù)校驗

常用的方式有這些：

• 自己封裝一個通用校驗JS文件，統(tǒng)一校驗方式（使用與JS發(fā)送請求）

• H5標簽屬性檢驗方式（適用于web form表單提交）

• 第三方JS自己封裝的校驗方法，這里對前端的建議盡量統(tǒng)一起來、規(guī)范起來。

3. 后端請求參數(shù)校驗

常用的方式有這些：

• 不校驗，我對比了之前開發(fā)的一些小系統(tǒng)（外包）對于后端參數(shù)基本沒有，這種方式的確可以做到后端開發(fā)快，所有的校驗都交給前端做，但對于前端不友好，如：由于前端少傳遞一個參數(shù)，導(dǎo)致后端程序報錯，而后端又沒有提供詳細的報錯信息，這給前端對接帶來了問題，前端不知道自己錯在哪里，這個時候可能還的和后端人員進行溝通，后端看看Log再告訴前端，這種方式對于前端對接不友好并且效率低。

• 封裝自己的校驗工具類進行檢驗，這種方式的確能做到后端交易，但如果需要校驗的參數(shù)比較多對程序是不友好的，如：

• 使用@RequestParam注解完成簡單非空校驗，這種雖然可以檢驗，但如果沒有傳此字段會拋出異常，這里需要通過全局異常捕獲統(tǒng)一處理。

@RequestParam(value = "mobile", required = true) String mobile

• 使用Interceptor、Filter、Aop.. 做公共部分的業(yè)務(wù)做統(tǒng)一的校驗處理，如：Token檢驗，權(quán)限校驗..

• 如果需要校驗的參數(shù)比較多，校驗方式和業(yè)務(wù)代碼混合在一塊不方便于代碼的維護，可以使用hibernate-validator來做分組校驗。

雖然到這里通過hibernate-validator來做分組校驗就可以解決所有方式的參數(shù)校驗：

• 分組管理不同接口參數(shù)校驗差異

• 可自定義注解校驗復(fù)雜情況

但也存在問題，后端校驗的確做到了，但如果要將這些參數(shù)校驗都編寫到接口文檔中，這個時候我們還需要先找接口、找到分組、找到dto下分組對應(yīng)的所有參數(shù)校驗，增加參數(shù)校驗規(guī)則還得重新修改接口文檔等等。

感謝各位的閱讀，以上就是“怎么規(guī)范web前后臺請求參數(shù)校驗”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對怎么規(guī)范web前后臺請求參數(shù)校驗這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！