Request data checking method and device
By using aspect-oriented programming (AOP) to obtain and parse validation annotations for request data, the validation groups of the interface are determined. Rules are written using Spring Expression Language, which solves the hard-coding problem of Spring Validation validation methods, enables flexible configuration and extension of validation rules, and improves the adaptability and availability of the system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- INSPUR SUZHOU INTELLIGENT TECH CO LTD
- Filing Date
- 2026-01-21
- Publication Date
- 2026-05-15
AI Technical Summary
Spring Validation's validation rules are hardcoded in POJOs, which means that modifications require recompilation and redeployment, affecting system availability. Furthermore, the validation rules for each POJO are separate and lack unified management, making it difficult to set differentiated rules and adapt validation rules to different scenarios under the same URL path.
Aspect-oriented programming (AOP) is used to define aspects, obtain target request data and its corresponding target validation annotations, determine whether the interface supports custom validation groups, determine the target validation group from pre-configured candidate groups based on validation annotations, and use Spring Expression Language to write validation rules for validation.
This achieves the separation of validation rules and code logic, improves the scalability and flexibility of validation rules, and enables the matching of appropriate validation rules according to actual conditions, thereby improving the adaptability and flexibility of the system.
Smart Images
Figure CN121560378B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the fields of computer technology and data processing technology, and in particular to a method, apparatus, device and storage medium for request data verification. Background Technology
[0002] In related technologies, Spring Validation hardcodes validation rules into Plain Old Java Objects (POJOs). Modifications require recompilation and redeployment, impacting system availability. Furthermore, the validation rules for each POJO are separate, lacking unified management. Under the same URL (Uniform Resource Locator), different request methods cannot set differentiated rules, and the same interface struggles to adapt to different validation rules in development, testing, and production scenarios. These issues inconvenience development and maintenance, and also affect the flexibility and adaptability of validation. Summary of the Invention
[0003] This application aims to at least partially address one of the technical problems in the related art.
[0004] In a first aspect, this application proposes a request data verification method, the method comprising: obtaining target request data and a target verification annotation of a target interface corresponding to the target request data based on an aspect defined using aspect-oriented programming (AOP); determining whether the target interface supports custom verification groups for request data based on the target verification annotation; if the target interface supports custom verification groups for request data, determining a custom target verification group from a plurality of pre-configured candidate verification groups based on the target request data or the target verification annotation; or, if the target interface does not support custom verification groups for request data, determining the target verification group from the plurality of candidate verification groups based on the target request method of the request to which the target request data belongs and / or the target verification annotation; and verifying the target request data based on the verification rules corresponding to the target verification group.
[0005] In one implementation, determining a custom target verification group from a plurality of pre-configured candidate verification groups based on the target request data or the target verification annotation includes: determining whether the request header of the target request data carries a first verification group identifier; and, if the request header of the target request data carries a first verification group identifier, determining the target verification group from the plurality of candidate verification groups based on the first verification group identifier.
[0006] In an optional implementation, determining a custom target verification group from a plurality of pre-configured candidate verification groups based on the target request data or the target verification annotation further includes: obtaining a second verification group identifier from the target verification annotation when the request header of the target request data does not carry a first verification group identifier; and determining the target verification group from the plurality of candidate verification groups based on the first verification group identifier.
[0007] In an optional implementation, the method further includes: if the request header of the target request data does not carry a first verification group identifier, determining the target verification group from the plurality of candidate verification groups based on the target request method of the request to which the target request data belongs and / or the target verification annotation.
[0008] In one implementation, determining the target verification group from the plurality of candidate verification groups based on the target request method of the request to which the target request data belongs and / or the target verification annotation includes: obtaining a pre-configured mapping relationship in the target verification annotation, wherein the mapping relationship is a mapping relationship between different request methods and verification group identifiers; obtaining the target request method corresponding to the target request data; obtaining the target verification group identifier corresponding to the target request method based on the mapping relationship; and determining the target verification group based on the target verification group identifier.
[0009] In an optional implementation, the step of determining the target verification group from the plurality of candidate verification groups based on the target request method of the request to which the target request data belongs and / or the target verification annotation further includes: if the target verification annotation does not contain the mapping relationship, obtaining a pre-configured second verification group identifier in the target verification annotation; and determining the target verification group from the plurality of candidate verification groups based on the second verification group identifier.
[0010] In one implementation, the step of obtaining target request data based on aspects defined using aspect-oriented programming (AOP) techniques, and the target verification annotation of the target interface corresponding to the target request data, includes: obtaining an interface call request based on the aspect; determining the interface to be called corresponding to the interface call request; identifying the interface method of the interface to be called; and, if the interface method includes the target verification annotation, obtaining the target request data from the interface call request.
[0011] In one implementation, determining whether the target interface supports custom validation groups for request data based on the target validation annotation includes: obtaining the boolean value of a first field in the target validation annotation; and determining whether custom validation groups for request data are supported based on the boolean value of the first field.
[0012] In one implementation, the validation rules are written in the Spring Expression Language. The validation of the target request data based on the validation rules corresponding to the target validation group includes: calling the Spring Expression Parsing Engine to parse the validation rules into executable code; and validating the target request data based on the executable code.
[0013] Secondly, this application proposes a request data verification device, the device comprising: an acquisition module, configured to acquire target request data and a target verification annotation of a target interface corresponding to the target request data based on an aspect defined using aspect-oriented programming (AOP); a first processing module, configured to determine whether the target interface supports custom verification groups for request data based on the target verification annotation; a second processing module, configured to determine a custom target verification group from a plurality of pre-configured candidate verification groups if the target interface supports custom verification groups for request data, based on the target request data or the target verification annotation; or, if the target interface does not support custom verification groups for request data, determine the target verification group from the plurality of candidate verification groups based on the target request method of the request to which the target request data belongs and / or the target verification annotation; and a third processing module, configured to verify the target request data based on the verification rules corresponding to the target verification group.
[0014] In one implementation, the second processing module can be used to: determine whether the request header of the target request data carries a first checksum identifier; and if the request header of the target request data carries a first checksum identifier, determine the target checksum from the plurality of candidate checksums based on the first checksum identifier.
[0015] In an optional implementation, the second processing module may further be used to: obtain the second verification group identifier in the target verification annotation if the request header of the target request data does not carry the first verification group identifier; and determine the target verification group from the plurality of candidate verification groups based on the first verification group identifier.
[0016] In an optional implementation, the second processing module may further be used to: determine the target verification group from the plurality of candidate verification groups based on the target request method of the request to which the target request data belongs and / or the target verification annotation, when the request header of the target request data does not carry the first verification group identifier.
[0017] In one implementation, the second processing module can be used to: obtain a pre-configured mapping relationship in the target verification annotation, wherein the mapping relationship is a mapping relationship between different request methods and verification group identifiers; obtain the target request method corresponding to the target request data; obtain the target verification group identifier corresponding to the target request method based on the mapping relationship; and determine the target verification group based on the target verification group identifier.
[0018] In an optional implementation, the second processing module may further be used to: obtain a pre-configured second verification group identifier in the target verification annotation if the target verification annotation does not contain the mapping relationship; and determine the target verification group from the plurality of candidate verification groups based on the second verification group identifier.
[0019] In one implementation, the acquisition module can be used to: acquire an interface call request based on the aspect; determine the interface to be called corresponding to the interface call request; identify the interface method of the interface to be called; and, if the interface method includes the target verification annotation, acquire target request data from the interface call request.
[0020] In one implementation, the first processing module can be used to: obtain the boolean value of the first field in the target validation annotation; and determine whether custom validation grouping of request data is supported based on the boolean value of the first field.
[0021] In one implementation, the validation rules are written in the Spring Expression Language, and the third processing module can be used to: call the Spring Expression Parsing Engine to parse the validation rules into executable code; and validate the target request data based on the executable code.
[0022] Thirdly, this application proposes an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the request data verification method as described in the first aspect.
[0023] Fourthly, this application proposes a storage medium storing instructions that, when executed on an electronic device, cause the electronic device to perform the method described in the first aspect.
[0024] Fifthly, this application proposes a program product comprising at least one of a program and instructions, wherein when the program or instructions are executed by an electronic device, they implement the steps of the method described in the first aspect.
[0025] The request data verification method, apparatus, device, and storage medium provided in this application can obtain target request data and target verification annotations of the target interface corresponding to the target request data through AOP aspects. Based on the target verification annotations, it determines whether the target interface supports custom verification groups for request data. According to the target interface's support for custom verification groups, it determines the target verification group from multiple candidate verification groups, and then verifies the target request data based on the verification rules corresponding to the target verification group. This enables the separation of verification rules and code logic, thereby significantly improving the extensibility of verification rules and allowing for matching appropriate verification rules according to actual conditions, enhancing verification flexibility and adaptability.
[0026] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description
[0027] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:
[0028] Figure 1 This is a flowchart illustrating a request data verification method provided in an embodiment of this application;
[0029] Figure 2 This is a flowchart illustrating another request data verification method provided in an embodiment of this application;
[0030] Figure 3 This is a flowchart illustrating another request data verification method provided in an embodiment of this application;
[0031] Figure 4 This is a flowchart illustrating another request data verification method provided in an embodiment of this application;
[0032] Figure 5 This is a flowchart illustrating a request data verification scheme provided in an embodiment of this application;
[0033] Figure 6 This is a schematic diagram of the structure of a request data verification device provided in an embodiment of this application;
[0034] Figure 7 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation
[0035] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.
[0036] The request data verification method and apparatus of this application are described below with reference to the accompanying drawings.
[0037] Figure 1 This is a flowchart illustrating a request data verification method provided in an embodiment of this application. Figure 1 As shown, the method may include, but is not limited to, the following steps:
[0038] S101: Obtain target request data and target validation annotations for the target interface corresponding to the target request data based on aspects defined using aspect-oriented programming techniques.
[0039] In some embodiments, validation annotations may include the Validate annotation and the ValidMethod annotation.
[0040] For example, based on a pre-created AOP (Aspect-Oriented Programming) aspect, when the interface is called by the front end, the request sent by the front end is intercepted, and the target request data to be validated is extracted from the request; at the same time, the AOP aspect identifies whether there is a Validate annotation on the method parameter by parsing the target interface method meta information corresponding to the request, and if so, extracts the Validate annotation as the target validation annotation.
[0041] In some embodiments, the above-mentioned acquisition of target request data based on aspects defined using aspect-oriented programming techniques, and the target verification annotation of the target interface corresponding to the target request data, may include the following steps: acquiring the interface call request based on the aspect; determining the interface to be called corresponding to the interface call request; identifying the interface method of the interface to be called; and, if the interface method includes a target verification annotation, acquiring the target request data from the interface call request.
[0042] For example, by intercepting the interface call request through a pre-created AOP aspect, the interface to be called corresponding to the interface call request is determined, and then the Controller class associated with the interface to be called is identified; if the Controller class contains the Validate annotation associated with the interface method corresponding to the interface to be called, the target request data to be validated is extracted from the interface call request, and the Validate annotation is obtained.
[0043] S102: Based on the target validation annotation, determine whether the target interface supports custom validation groups for request data.
[0044] For example, based on the values of preset fields in the target validation annotation, it is determined whether the target interface supports custom validation groups for request data.
[0045] In some embodiments, determining whether a target interface supports custom validation groups for request data based on target validation annotations may include the following steps A1 and A2:
[0046] A1: Get the boolean value of the first field in the target validation annotation.
[0047] In some embodiments, the first field mentioned above can be the allowDefine field.
[0048] For example, the `allowDefine` field can be predefined in the `@Validate` annotation to specify whether custom group names are allowed. If customization is allowed, the validation group identifier used to determine the target validation group is passed by the front end; if customization is not allowed, the validation group identifier used to determine the target validation group can only be obtained through other fields in the `@Validate` annotation.
[0049] For example, obtain the boolean value of the allowDefine field in the Validation associated with the interface method of the target interface.
[0050] A2: Based on the boolean value of the first field, determine whether custom validation groups for requested data are supported.
[0051] As an example, if the boolean value of the allowDefine field in the Validation associated with the target interface method is true, then it is determined that the target interface supports custom validation groups for request data.
[0052] As another example, if the boolean value of the allowDefine field in the Validation associated with the target interface method is false, then it is determined that the target interface does not support custom validation groups for request data.
[0053] S103: If the target interface supports custom validation groups for request data, determine the custom target validation group from multiple pre-configured candidate validation groups based on the target request data or target validation annotation; or, if the target interface does not support custom validation groups for request data, determine the target validation group from multiple candidate validation groups based on the target request method and / or target validation annotation of the request to which the target request data belongs.
[0054] As an example, when the target interface supports custom validation groups for request data, the target validation group specified by the front end is determined from multiple pre-configured candidate validation groups based on the relevant information of the validation group specified in the target request data.
[0055] As another example, if the target interface supports custom validation groups for request data, and the target request data does not carry information related to the specified validation group, the custom target validation group is determined from multiple pre-configured candidate validation groups based on the target validation annotation.
[0056] As another example, when the target interface does not support custom validation groups for request data, the target validation group is determined from multiple candidate validation groups based on the target request method of the target request data.
[0057] As another example, when the target interface does not support custom validation groups for request data, the target validation group is determined from multiple candidate validation groups based on the target validation annotation.
[0058] It should be noted that, in the embodiments of this application, each verification group corresponds to at least one verification rule.
[0059] S104: Verify the target request data based on the verification rules corresponding to the target verification group.
[0060] For example, the validation rules corresponding to the "insert" validation group can be: id=null message="Insert cannot contain ID", meaning that when performing the "insert" operation, the id field in the request data must be null. If the id field has a specific value (not null), the validation fails and returns the message "Insert cannot contain ID"; name!=null and name!=" message="Name cannot be an empty string", meaning that the name field in the validation request data must not be null and cannot be an empty string (without any characters). If it does not meet the requirements, the validation fails and returns the message "Name cannot be an empty string"; hasScheme!=null message="Must specify is "Whether to include a proposal" means checking if the value of the hasScheme field in the request data is not null. If it is null, a validation failure message is thrown: "Whether to include a proposal must be specified; hasScheme?(scheme!=nulllandscheme.length()>0):(scheme==null|scheme.isEmpty())message="Proposal content must be specified when including a proposal" means that different validations are performed on the scheme field based on the boolean value of the hasScheme field, ultimately ensuring that "a valid proposal must be filled in when including a proposal, and no proposal content must be filled in when not including a proposal". If this is not satisfied, the message "Proposal content must be specified when including a proposal" is returned.
[0061] By implementing the embodiments of this application, target request data and target validation annotations of the target interface corresponding to the target request data can be obtained through AOP aspects. Based on the target validation annotations, it can be determined whether the target interface supports custom validation groups for request data. Then, based on the target interface's support for custom validation groups, the target validation group is determined from multiple candidate validation groups. Finally, the target request data is validated based on the validation rules corresponding to the target validation group. This enables the separation of validation rules and code logic, significantly improving the extensibility of validation rules and allowing for matching appropriate validation rules according to actual conditions, thus enhancing validation flexibility and adaptability.
[0062] In some embodiments, where the target interface supports custom validation groups for request data, the specified validation group can be preferentially determined as the target validation group based on the target request data. For an example, please refer to [link to example]. Figure 2 , Figure 2 This is a flowchart illustrating another request data verification method provided in an embodiment of this application. Figure 2 As shown, the method may include, but is not limited to, the following steps:
[0063] S201: Obtain target request data and target validation annotations for the target interface corresponding to the target request data based on aspects defined using aspect-oriented programming techniques.
[0064] In the embodiments of this application, step S201 can be implemented in any of the ways described in the embodiments of this application. The embodiments of this application do not limit this, nor will they be described in detail.
[0065] S202: Based on the target validation annotation, determine whether the target interface supports custom validation groups for request data.
[0066] In the embodiments of this application, step S202 can be implemented in any of the ways described in the embodiments of this application. The embodiments of this application do not limit this, nor will they be described in detail.
[0067] S203: If the target interface supports custom validation groups for request data, determine whether the request header of the target request data carries the first validation group identifier.
[0068] For example, when the target interface supports custom validation groups for request data, the header of the request to which the target request data belongs is parsed to determine whether it contains a preset target validation group identifier (e.g., a specified Header field) and its corresponding valid value, thereby determining whether the identifier exists in the request header.
[0069] In some embodiments, the `@Validate` annotation can define a `validHeader` field to specify in which request header the validation group identifier is stored when the front-end transmits the validation group identifier. For example, the `validHeader` field can be "X-Validate-Header".
[0070] S204: If the request header of the target request data carries a first verification group identifier, determine the target verification group from multiple candidate verification groups based on the first verification group identifier; or, if the target verification group identifier does not exist in the request header of the target request data, obtain the first verification group identifier in the target verification annotation as the target verification group identifier.
[0071] In some embodiments, the ValidMethod annotation can be predefined to specify the respective validation rules for each request method. The ValidMethod annotation can include multiple sets of corresponding method fields and value fields. The method field is used to specify the request method type, and the value field is used to specify the group name, so that the corresponding first validation group identifier can be determined based on the request method type of the target request data.
[0072] As an example, if the request header of the target request data carries a first checksum identifier, the first checksum identifier is obtained from the request header, and the target checksum is determined based on the first checksum identifier.
[0073] For example, a validation group A containing several validation rules can be predefined. If the request header of the target request data carries the validation group identifier of validation group A, then validation group A will be used as the target validation group.
[0074] As another example, if the target checksum identifier is not present in the request header of the target request data, the default checksum identifier is taken from the target configuration information and used as the target checksum identifier.
[0075] It should be noted that for interfaces that support custom validation groups for request data, the default validation group can be specified in the validation annotation of the interface. If the frontend specifies the target validation group identifier through the request header, the target validation group identifier specified in the request header will be used first; if the frontend does not specify the target validation group identifier, the default validation group specified in the validation annotation of the interface will be used as the target validation group identifier.
[0076] In some embodiments, the above method may further include: if there is no target verification group identifier in the request header of the target request data, determining the target verification group from multiple candidate verification groups based on the target request method and / or target verification annotation of the request to which the target request data belongs.
[0077] In one alternative implementation, if the target validation group is not determined from multiple candidate validation groups based on the target request method and / or target validation annotation of the request to which the target request data belongs, an exception message can be generated.
[0078] S205: Determine the target check group from multiple candidate check groups based on the target check group identifier.
[0079] For example, the `@Validate` annotation can define a `methods` field to specify the corresponding validation group name for each request method.
[0080] For example, from multiple candidate verification groups, a group that matches the target verification group identifier is selected as the target verification group.
[0081] S206: Verify the target request data based on the verification rules corresponding to the target verification group.
[0082] In the embodiments of this application, step S206 can be implemented in any of the ways described in the embodiments of this application. The embodiments of this application do not limit this, nor will they be described in detail.
[0083] By implementing the embodiments of this application, when the target interface supports custom validation groups for request data, the target validation group identifier can be obtained from the request header of the target request data. The target validation group can then be determined based on the target validation group identifier, and the target request data can be validated based on the validation rules corresponding to the target validation group. This enables custom validation based on front-end instructions.
[0084] In some embodiments, if the target interface does not support custom validation, the target validation group can be determined from multiple candidate validation groups based on the target request method and / or target validation annotation of the request to which the target request data belongs. For an example, please refer to [link to example]. Figure 3 , Figure 3 This is a flowchart illustrating another request data verification method provided in an embodiment of this application. For example... Figure 3 As shown, the method may include, but is not limited to, the following steps:
[0085] S301: Obtain target request data and target validation annotations for the target interface corresponding to the target request data based on aspects defined using aspect-oriented programming techniques.
[0086] In the embodiments of this application, step S301 can be implemented in any of the embodiments of this application. The embodiments of this application do not limit this and will not be described in detail.
[0087] S302: Based on the target validation annotation, determine whether the target interface supports custom validation groups for request data.
[0088] In the embodiments of this application, step S302 can be implemented in any of the ways described in the embodiments of this application. The embodiments of this application do not limit this, nor will they be described in detail.
[0089] S303: If the target interface does not support custom validation groups for request data, obtain the pre-configured mapping relationship in the target validation annotation. The mapping relationship is the mapping relationship between different request methods and validation group identifiers.
[0090] In the embodiments of this application, the above request methods may include, but are not limited to: GET (query), POST (submit), PUT (update), DELETE (delete), and PATCH (partial update).
[0091] For example, if the target interface does not support custom validation groups for request data, obtain the mapping relationship between different request methods and validation group identifiers pre-configured in the methods configuration item of the Validate annotation.
[0092] As an example, the validation group identifier for a POST request can be insert, and the validation group identifier for a PUT request can be update. Both the insert and update groups have at least one pre-specified validation rule.
[0093] S304: Get the target request method corresponding to the target request data.
[0094] S305: Based on the mapping relationship, obtain the target verification group identifier corresponding to the target request method.
[0095] As an example, if the validation group identifier for a POST request is insert, the validation group identifier for a PUT request is update, and the target request method for the target request data is POST, then the target validation group identifier corresponding to the target request method is insert.
[0096] In other embodiments, if the target verification annotation does not contain a mapping relationship, the second verification group identifier in the target verification annotation is obtained as the target verification group identifier.
[0097] For example, the Validate annotation can have a predefined value field to specify a validation group identifier as the second validation group identifier mentioned above. This allows the target validation group identifier to be determined based on the predefined field in the Validate annotation, even if the target validation annotation does not contain a mapping relationship.
[0098] S306: Determine the target check group based on the target check group identifier.
[0099] In the embodiments of this application, step S306 can be implemented in any of the embodiments of this application. The embodiments of this application do not limit this and will not be described in detail.
[0100] S307: Verify the target request data based on the verification rules corresponding to the target verification group.
[0101] In the embodiments of this application, step S307 can be implemented in any of the embodiments of this application. The embodiments of this application do not limit this and will not be described in detail.
[0102] By implementing the embodiments of this application, even when the target interface does not support custom validation, the target validation group can be determined primarily based on the request method corresponding to the request data, combined with the mapping relationship between the request method and validation group in the target validation configuration information. This improves the adaptability of data validation.
[0103] In one implementation, the validation rules corresponding to each candidate validation group are written using Spring Expression Language. When validating request data based on these rules, the validation rules can be parsed first. For an example, please refer to [link to example]. Figure 4 , Figure 4 This is a flowchart illustrating another request data verification method provided in an embodiment of this application. Figure 4 As shown, the method may include, but is not limited to, the following steps:
[0104] S401: Obtain target request data and target validation annotations for the target interface corresponding to the target request data based on aspects defined using aspect-oriented programming techniques.
[0105] In the embodiments of this application, step S401 can be implemented in any of the ways described in the embodiments of this application. The embodiments of this application do not limit this, nor will they be described in detail.
[0106] S402: Based on the target validation annotation, determine whether the target interface supports custom validation groups for request data.
[0107] In the embodiments of this application, step S402 can be implemented in any of the ways described in the embodiments of this application. The embodiments of this application do not limit this, nor will they be described in detail.
[0108] S403: If the target interface supports custom validation groups for request data, determine the custom target validation group from multiple pre-configured candidate validation groups based on the target request data or target validation annotation; or, if the target interface does not support custom validation groups for request data, determine the target validation group from multiple candidate validation groups based on the target request method and / or target validation annotation of the request to which the target request data belongs.
[0109] In the embodiments of this application, step S403 can be implemented in any of the embodiments of this application. The embodiments of this application do not limit this and will not be described in detail.
[0110] S404: Calls the Spring expression parsing engine to parse the validation rules into executable code.
[0111] For example, the Spring expression parsing engine is invoked to parse the validation rules into executable Java code.
[0112] S405: Verify the target request data based on the executable code.
[0113] For example, the request data is validated based on the Java code in the aforementioned steps.
[0114] By implementing the embodiments of this application, validation rules can be stored using SpEL expression rules, and when needed, the Spring expression parsing engine can parse the validation rules into executable code. This decouples validation rules from program code, improving the efficiency of configuring and changing validation rules.
[0115] In some embodiments, the above method may further include: scanning all interface methods in the Controller class that are annotated with parameters using the Validate annotation; obtaining the configuration information of the Validate annotation corresponding to each interface; generating an interactive interface based on the configuration information of the Validate annotation corresponding to each interface, so that the interactive object can configure the configuration information of the Validate annotation corresponding to each interface based on the interactive interface.
[0116] For example, a scanning class `ValidateAnnotationScanner` is defined for global scanning of `@Validate` annotations. When the system starts, `@ValidateAnnotationScanner` automatically scans all Controller classes globally, finds all interface methods that use the `@Validate` annotation, parses these methods, and obtains the associated request URL, request method, validation group, and custom parameter names annotated with `@Validate`, etc., for users to reference when using SpEL expressions to customize validation methods through the front-end web page.
[0117] In some embodiments, the above method may further include: obtaining the verification rules corresponding to each candidate verification group; generating an interactive interface based on the verification rules corresponding to each candidate verification group, so that the interactive object can configure the verification rules corresponding to each candidate verification group based on the interactive interface, thereby improving the configuration efficiency of the verification rules.
[0118] The configuration information mentioned above includes at least one of the following: the defined custom validation group name, the request URL path, the supported request methods, the validation group name for each request method if multiple request methods are supported, whether custom group names are allowed, the custom name of the annotated parameters, the field names in the parameter class and related information.
[0119] Please see Figure 5 , Figure 5 This is a flowchart illustrating a request data verification scheme provided in an embodiment of this application, such as... Figure 5As shown, firstly, the `@Validate` annotation class, which implements validation rules, is defined. Its function is to mark the received parameters of the request entry point in the Controller class of the interface method, specifying the group to be used for validation in the current request URL. Secondly, the `ValidateScanner` scanning class is defined for global scanning of the `@Validate` annotation. At system startup, it automatically scans all Controllers globally, finds all interface methods using the `@Validate` annotation, parses each interface method, and obtains the associated request URL, request method, validation group, and custom parameter names annotated with `@Validate`, etc., for users to refer to when using SpEL expressions to customize validation methods through the front-end web page. Thirdly, a database table and its associated tables are defined to record the scan results. This includes a table of parsed URLs and request methods from the previous steps, a custom group table, and a table of multiple custom validation rules associated with each group. Finally, an aspect that recognizes the `@Validate` annotation is defined to intercept and validate the request method when receiving the actual request. Finally, a display page and related interfaces for the front-end to show the parsed results and the specified SpEL expression results are written.
[0120] When the program starts, it scans all methods in the Controller class that have parameters annotated with `@Validate`, retrieving the custom validation group name defined in the annotation, the request URL path, supported request methods, the validation group name for each request method if multiple request methods are supported, whether custom group names are allowed, the custom name of the annotated parameter, the field names in the parameter class, and related information. The parsed results are recorded in a scan result table and a related table. An interactive interface is provided, allowing users to configure validation groups and corresponding validation rules, and specify failure information for each validation rule.
[0121] After the frontend sends a request, the AOP aspect intercepts the interface method annotated with `@Validate` and executes its aspect method. It analyzes and finds all defined validation rule group names, ultimately confirming which validation group is effective according to a preset recognition order. It then searches the database for the rule list corresponding to the effective group name, sequentially calling the Spring expression parsing engine to parse the rules into executable Java code and perform validation. If all validations pass, subsequent code execution continues; if validation fails, the corresponding failure information is retrieved, thrown, and returned.
[0122] The specific identification order is as follows: If `allowDefine` is true, when the front end passes the request header via `validHeader`, the validation process automatically searches for the validation rule corresponding to the passed group name. If not found, execution continues to the next step. If `methods` exists, the request method of the current request is parsed, and its specified validation group name and corresponding validation rule list are searched. If not found, execution continues to `value`. If `value` exists, the validation group name specified in `value` and its corresponding validation rule list are searched. If `value` does not exist or is not found, a validation group lookup failure exception is thrown.
[0123] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a request data verification device provided in an embodiment of this application. Figure 6 As shown, the device 600 includes: an acquisition module 601, used to acquire target request data and target validation annotations of the target interface corresponding to the target request data based on aspects defined using aspect-oriented programming (AOP) technology; a first processing module 602, used to determine whether the target interface supports custom validation groups for request data based on the target validation annotations; a second processing module 603, used to determine a custom target validation group from a plurality of pre-configured candidate validation groups based on the target request data or the target validation annotations if the target interface supports custom validation groups for request data; or, if the target interface does not support custom validation groups for request data, to determine a target validation group from a plurality of candidate validation groups based on the target request method and / or the target validation annotations of the request to which the target request data belongs; and a third processing module 604, used to validate the target request data based on the validation rules corresponding to the target validation group.
[0124] In one implementation, the second processing module 603 can be used to: determine whether the request header of the target request data carries a first checksum identifier; if the request header of the target request data carries a first checksum identifier, determine the target checksum from multiple candidate checksums based on the first checksum identifier.
[0125] In an alternative implementation, the second processing module 603 may also be used to: obtain the second verification group identifier in the target verification annotation when the request header of the target request data does not carry the first verification group identifier; and determine the target verification group from multiple candidate verification groups based on the first verification group identifier.
[0126] In an alternative implementation, the second processing module 603 may also be used to: determine the target verification group from multiple candidate verification groups based on the target request method and / or target verification annotation of the request to which the target request data belongs, when the request header of the target request data does not carry the first verification group identifier.
[0127] In one implementation, the second processing module 603 can be used to: obtain a pre-configured mapping relationship in the target verification annotation, wherein the mapping relationship is a mapping relationship between different request methods and verification group identifiers; obtain the target request method corresponding to the target request data; obtain the target verification group identifier corresponding to the target request method based on the mapping relationship; and determine the target verification group based on the target verification group identifier.
[0128] In an alternative implementation, the second processing module 603 may also be used to: obtain a pre-configured second verification group identifier in the target verification annotation when the target verification annotation does not contain a mapping relationship; and determine the target verification group from multiple candidate verification groups based on the second verification group identifier.
[0129] In one implementation, the acquisition module 601 can be used to: acquire interface call requests based on aspects; determine the interface to be called corresponding to the interface call request; identify the interface method of the interface to be called; and, if the interface method includes a target validation annotation, acquire the target request data from the interface call request.
[0130] In one implementation, the first processing module 602 can be used to: obtain the boolean value of the first field in the target validation annotation; and determine whether custom validation grouping of request data is supported based on the boolean value of the first field.
[0131] In one implementation, the validation rules are written in the Spring Expression Language, and the third processing module 604 can be used to: call the Spring Expression Parsing Engine to parse the validation rules into executable code; and validate the target request data based on the executable code.
[0132] The apparatus of this application embodiment can obtain target request data and target validation annotations of the target interface corresponding to the target request data through AOP aspects. Based on the target validation annotations, it determines whether the target interface supports custom validation groups for the request data. According to the target interface's support for custom validation groups, a target validation group is determined from multiple candidate validation groups. Then, based on the validation rules corresponding to the target validation group, the target request data is validated. This achieves separation of validation rules and code logic, significantly improving the extensibility of validation rules and enabling the matching of appropriate validation rules according to actual conditions, thus enhancing validation flexibility and adaptability.
[0133] It should be noted that the foregoing explanation of the request data verification method embodiment also applies to the request data verification device of this embodiment, and will not be repeated here.
[0134] To implement the above embodiments, this application also proposes an electronic device. Please see [link to relevant documentation]. Figure 7 , Figure 7 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 7 As shown, the electronic device 700 includes: a processor 701 and a memory 702 communicatively connected to the processor 701; the memory 702 stores computer execution instructions; the processor 701 executes the computer execution instructions stored in the memory to implement the method provided in the foregoing embodiments.
[0135] To implement the above embodiments, this application also proposes a storage medium storing instructions that, when executed on an electronic device, cause the electronic device to perform the methods provided in the foregoing embodiments.
[0136] To implement the above embodiments, this application also proposes a program product, including at least one of a program and instructions, wherein when the program and instructions are executed by an electronic device, they implement the steps of the method provided in the foregoing embodiments.
[0137] It should be noted that the acquisition, transmission, storage, use, and processing of data in this application comply with the relevant provisions of national laws and regulations and do not violate public order and good morals.
[0138] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.
[0139] It is worth noting that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, they do not mean that the applicant has used or necessarily used the solution.
[0140] In the description of this application, unless otherwise stated, " / " means "or", for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone.
[0141] In the foregoing descriptions of the embodiments, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.
[0142] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.
[0143] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.
[0144] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.
[0145] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.
[0146] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.
[0147] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.
[0148] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.
Claims
1. A method for verifying requested data, characterized in that, include: The target request data is obtained based on the aspect defined using aspect-oriented programming, and the target validation annotation of the target interface corresponding to the target request data; Based on the target validation annotation, determine whether the target interface supports custom validation groups for request data; When the target interface supports custom validation groups for request data, a custom target validation group is determined from a plurality of pre-configured candidate validation groups based on the target request data or the target validation annotation, including: Determine whether the request header of the target request data carries a first checksum identifier; If the request header of the target request data carries a first checksum identifier, the target checksum is determined from the plurality of candidate checksums based on the first checksum identifier; If the request header of the target request data does not carry the first verification group identifier, the second verification group identifier in the target verification annotation is obtained; The target verification group is determined from the plurality of candidate verification groups based on the second verification group identifier; Alternatively, if the target interface does not support custom validation groups for request data, the target validation group is determined from the plurality of candidate validation groups based on the target request method of the request to which the target request data belongs and the target validation annotation, including: Obtain the pre-configured mapping relationship in the target verification annotation, wherein the mapping relationship is the mapping relationship between different request methods and verification group identifiers; The target request method corresponding to the target request data; Based on the mapping relationship, obtain the target verification group identifier corresponding to the target request method; The target verification group is determined based on the target verification group identifier; If the target verification annotation does not contain the mapping relationship, obtain the pre-configured second verification group identifier in the target verification annotation; The target verification group is determined from the plurality of candidate verification groups based on the second verification group identifier; The target request data is verified based on the verification rules corresponding to the target verification group.
2. The method according to claim 1, characterized in that, The method further includes: If the request header of the target request data does not carry a first verification group identifier, the target verification group is determined from the plurality of candidate verification groups based on the target request method of the request to which the target request data belongs and / or the target verification annotation.
3. The method according to claim 1, characterized in that, The process of obtaining target request data based on aspects defined using aspect-oriented programming (AOP) techniques, and the target validation annotations of the target interfaces corresponding to the target request data, includes: Based on the aforementioned aspect, obtain the interface call request; Determine the interface to be called corresponding to the interface call request; Identify the interface methods of the interface to be called; When the interface method includes the target validation annotation, the target request data is obtained from the interface call request.
4. The method according to claim 1, characterized in that, The step of determining whether the target interface supports custom validation groups for request data based on the target validation annotation includes: Obtain the boolean value of the first field in the target validation annotation; Based on the boolean value of the first field, determine whether custom validation groups for requested data are supported.
5. The method according to claim 1, characterized in that, The validation rules are written in Spring Expression Language. The validation of the target request data based on the validation rules corresponding to the target validation group includes: The Spring expression parsing engine is invoked to parse the validation rules into executable code. The target request data is validated based on the executable code.
6. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 5.