Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to standardize web foreground and background request parameter verification". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to standardize web foreground and background request parameter verification".

1. When will we check the front and back end?

Under normal circumstances, both the front and back end need to verify the requested parameters, which can improve the stability and maintainability of the application. For the front and background, if the indispensable verification rules can be summarized and a set of specifications can be developed, the use of this specification in every application can bring a lot of benefits. In which cases is it appropriate to use front-end and back-end verification:

The application has a single business, less post-maintenance, and does not involve sensitive information, such as the company's internal OA system, which can directly use front-end verification, where the front-end parameter verification can be used: H5 form verification or encapsulate commonly used verification JS files.

The application has a single business and less maintenance in the later stage, such as the payment system, because the payment system may have interfaces for other companies to connect to the platform, all this front-end verification will be left to other companies, and we only need to do a good back-end verification.

Complex business, many post-maintenance, high security and availability requirements, such as: e-commerce project maintenance, this method needs to use front-end verification at the same time. The purpose of front-end verification is to intercept and process more error requests at the browser level, which does not consume server memory and threads, and can provide performance. For the back-end verification is to improve the stability of the system, do not move on 500, but also can prevent some people from malicious attacks on the website and so on.

two。 Front-end request parameter verification

The common ways are as follows:

Encapsulate a general verification JS file and unify the verification method (using JS to send requests)

H5 tag attribute verification method (suitable for web form form submission)

The verification method encapsulated by the third-party JS itself. Here, the suggestions for the front end are unified and standardized as far as possible.

3. Backend request parameter verification

The common ways are as follows:

Without verification, I compared some previously developed small systems (outsourcing) with basically no back-end parameters. This method can indeed make the back-end development fast, and all the verification is left to the front-end, but it is not friendly to the front-end. For example, because the front-end passes a parameter less, the back-end program reports an error, and the back-end does not provide detailed error information, which brings problems to the front-end docking. The front end does not know where it is wrong, and may communicate with the back end staff at this time. The back end looks at the Log and then tells the front end that this way is not friendly and inefficient for the front end docking.

Encapsulating your own verification tool class for verification, it is true that backend transactions can be achieved in this way, but it is unfriendly to the program if more parameters need to be verified, such as:

Use the @ RequestParam annotation to complete a simple non-empty check. This can be verified, but if this field is not passed, an exception will be thrown. Here, you need to handle it uniformly through global exception capture.

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

Use Interceptor, Filter, Aop.. Do the public part of the business to do unified verification processing, such as: Token inspection, authority verification..

If there are many parameters that need to be verified, the combination of verification method and business code is not convenient for the maintenance of the code. You can use hibernate-validator to do group verification.

Although you can do group verification through hibernate-validator here, you can solve all kinds of parameter verification:

Check differences of different interface parameters in packet management

Customizable annotations to check complex situations

However, there are also problems. The back-end verification is indeed achieved, but if we want to write all these parameter verifications into the API document, we also need to find the interface, find the grouping, find all the parameter verifications corresponding to the grouping under the dto, add the parameter verification rules, and modify the API document again.

Thank you for your reading, the above is the content of "how to standardize web foreground and background request parameter verification". After the study of this article, I believe you have a deeper understanding of how to standardize web foreground and background request parameter verification, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.