Interface verification method and device based on dynamic rule, medium and program product

Abstract

The embodiment of the invention provides an interface verification method and device based on a dynamic rule, a medium and a program product, and relates to the technical field of parameter verification. The method comprises the following steps: before calling interface processing, acquiring a user-defined annotation associated with an interface; determining a to-be-verified field and corresponding rule index information based on the user-defined annotation; acquiring a corresponding target verification rule from a rule cache list based on the rule index information; wherein the rule cache list is loaded and cached on the basis of a dynamic rule base under the condition of compiling initialization or rule change; and verifying the corresponding field to be verified based on the target verification rule. According to the embodiment of the invention, a cache rule-oriented verification mode is adopted to dynamically adapt to the business change of the rule base, so that the interface verification efficiency in a dynamic business scene can be effectively improved, and the maintenance cost can be reduced.

Description

Technical Field

[0001] This application relates to the field of parameter verification technology, and more specifically, to an interface verification method, device, medium, and program product based on dynamic rules. Background Technology

[0002] In the development of software systems, it is often necessary to perform necessary validity checks on user input parameters, such as whether the input parameter is empty, whether the length exceeds the limit, whether the format conforms to the convention, and the data range. The validation method is to obtain the specific value of the user input for the validation field and the Java annotation of the validation field through the Java object field mechanism, and then validate the specific value according to the Java annotation of the validation field. If the validation fails, an exception is thrown, which includes the error information corresponding to the Java annotation.

[0003] However, traditional solutions (such as Bean Validation) only support predefined annotations and rule validation, lacking a mechanism for dynamically configuring rules. If a field rule is added or changed temporarily, it needs to be recompiled and deployed to implement the new rule validation process, which is inefficient and has high maintenance costs, and cannot adapt to dynamic business needs. Summary of the Invention

[0004] The purpose of this application is to provide an interface verification method, device, medium, and program product based on dynamic rules, so as to improve the interface verification efficiency in dynamic business scenarios.

[0005] In a first aspect, embodiments of this application provide an interface verification method based on dynamic rules, including: Before calling the interface, obtain the custom annotations associated with the interface; Based on the custom annotation, determine the fields to be verified and the corresponding rule index information; The corresponding target verification rule is retrieved from the rule cache list based on the rule index information; wherein, the rule cache list is loaded and cached based on a dynamic rule library when the compilation is initialized or when rule changes occur; The corresponding fields to be verified are verified based on the target verification rules.

[0006] In this embodiment of the application, by adopting a validation method oriented towards cache rules, the system can dynamically adapt to business changes in the rule base, which can effectively improve the efficiency of interface validation in dynamic business scenarios and reduce maintenance costs.

[0007] In some embodiments, the interface verification method based on dynamic rules further includes: In response to a rule modification instruction, a target rule identifier and corresponding rule update content are determined based on the rule modification instruction; wherein, the rule modification instruction is triggered when a rule content change is detected in the dynamic rule base; Based on the rule update content, the rules corresponding to the target rule identifier in the rule cache list are cached and updated.

[0008] In this embodiment of the application, by monitoring changes in the rule content of the dynamic rule base in real time and triggering timely updates to the rule cache list, the efficiency of interface verification is further improved.

[0009] In some embodiments, the interface verification method based on dynamic rules further includes: In response to a business change instruction, the rule cache list is reloaded based on the current dynamic rule base; The business change instruction is triggered when a rule addition or deletion event is detected in the dynamic rule base.

[0010] In this embodiment, the reliability of interface verification is further improved by reloading the rule cache list when a new or deleted rule is detected in the dynamic rule base.

[0011] In some embodiments, the interface verification method based on dynamic rules further includes: If a change event is detected in the rule cache list, the corresponding second target verification rule is retrieved from the changed rule cache list based on the rule index information; wherein, the change event includes cache update or reload; The corresponding fields to be verified are verified based on the second target verification rule.

[0012] In this embodiment of the application, by automatically detecting changes in the rule cache table and automatically triggering the re-verification process, the reliability and efficiency of verification are further improved.

[0013] In some embodiments, the interface verification method based on dynamic rules further includes: Obtain the first verification result of the corresponding field to be verified based on the target verification rule; Obtain the second verification result based on the second target verification rule for the corresponding field to be verified; Difference location information is generated based on the comparison between the first verification result and the second verification result; wherein, the difference location information includes the fields to be verified where the verification results differ, their corresponding target verification rules, and the second target verification rule.

[0014] In this embodiment of the application, by updating the rule cache table and re-triggering the verification process, the difference location information between the two verifications before and after the update is obtained, further improving development efficiency.

[0015] In some embodiments, the interface verification method based on dynamic rules further includes: If a change event is detected in the rule cache list, and the corresponding verification rule cannot be obtained from the rule cache list after the change based on the rule index information, an annotation exception message is issued; wherein, the annotation exception message includes custom annotation information corresponding to the field to be verified.

[0016] In this embodiment of the application, if the target validation rule corresponding to the annotation index information cannot be obtained during the re-validation process after the rule cache list is changed, an annotation exception prompt is triggered, which further improves development efficiency.

[0017] In some embodiments, the interface verification method based on dynamic rules further includes: If it is determined that the custom annotation has changed, the corresponding verification rule to be updated is obtained from the dynamic rule base; If the changes to the custom annotation meet the preset automatic update conditions, the verification rules to be updated are modified based on the changes to obtain the updated verification rules. The dynamic rule base is updated based on the updated verification rules.

[0018] In this embodiment of the application, the interface verification efficiency is further improved by automatically updating the verification rules according to the changed content when the annotation changes.

[0019] In some embodiments, the step of validating the corresponding field to be validated based on the target validation rule includes: The corresponding validation logic is determined based on the custom annotation. According to the verification logic, the corresponding fields to be verified are verified based on the target verification rules.

[0020] In this embodiment of the application, the flexibility of interface verification is further improved by determining the corresponding verification logic based on the annotation and implementing interface verification according to the specific verification logic.

[0021] In some embodiments, the dynamic rule base includes basic validation rules and combined validation rules; wherein, the basic validation rules include at least one of regular expression validation rules, range threshold validation rules, and format validation rules, and the combined validation rules are validation rules that combine multiple basic validation rules using logical operators.

[0022] In this embodiment of the application, by setting multiple basic validation rules that support regular expressions, range thresholds and format validation, as well as validation rules that combine multiple basic validation rules using logical operators, the flexibility of validation is further improved.

[0023] Secondly, embodiments of this application provide an interface verification device based on dynamic rules, comprising: The annotation acquisition module is used to acquire custom annotations associated with the interface before calling the interface for processing. The information determination module is used to determine the field to be verified and the corresponding rule index information based on the custom annotation; The rule acquisition module is used to retrieve the corresponding target verification rule from the rule cache list based on the rule index information; wherein, the rule cache list is loaded and cached based on a dynamic rule library when the compilation is initialized or when rule changes occur; The field validation module is used to validate the corresponding fields to be validated based on the target validation rules.

[0024] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, can implement the method described in any embodiment of the first aspect.

[0025] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the method described in any embodiment of the first aspect.

[0026] Fifthly, embodiments of this application provide a computer program product, the computer program product including a computer program, wherein when the computer program is executed by a processor, it can implement the method described in any embodiment of the first aspect. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 A flowchart illustrating an interface verification method based on dynamic rules provided in this application embodiment; Figure 2A schematic diagram of the structure of an interface verification device based on dynamic rules provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0029] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0030] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0031] It should be noted that in existing technologies (such as Bean Validation), validation methods obtain the specific value input by the user for the validation field and the Java annotation of that field through the Java object field mechanism. The specific value is then validated based on the Java annotation. If validation fails, an exception is thrown, containing the corresponding error information from the Java annotation. Alternatively, Java-validation and Spring validation technologies trigger the validation process by adding annotations such as @NotNull, @Size, and @Email to the fields requiring validation, and setting the @Valid or @Validated annotation in the method signature using that parameter.

[0032] However, the traditional validation schemes mentioned above only support predefined annotation validation, which cannot adapt to dynamic business needs, such as temporarily adding or changing field rules; and the validation logic is coupled with business code, changes require recompilation and deployment, and there is a lack of rule version management and hot reloading mechanism, resulting in low interface validation efficiency and high maintenance costs.

[0033] It's important to note that Bean Validation (such as Hibernate Validator) typically uses annotations to define validation rules, such as `@NotNull` and `@Size`. These annotations are written to the class file at compile time, making them static. During validation, the validator reads these annotations via reflection and then validates the field values ​​according to the annotation rules. Since the annotation values ​​are determined at compile time and written to the class file, they cannot be modified at runtime. Furthermore, the validator typically parses the annotation information in the class and generates the corresponding validation rules during initialization—a process that occurs only when the application starts and remains unchanged afterward. Therefore, if we want to dynamically change the validation rules, we need a mechanism to update these rules at runtime.

[0034] To address the problems existing in the prior art, this application provides an interface verification method based on dynamic rules, which can effectively improve the efficiency of interface verification and reduce maintenance costs.

[0035] like Figure 1 As shown in the figure, this application provides an interface verification method based on dynamic rules, which may include the following steps: S1. Before calling the interface for processing, obtain the custom annotations associated with the interface.

[0036] Specifically, before the code is compiled to the point of calling an interface for processing, parameter validation can be performed through a pre-defined interceptor to avoid the execution of invalid business logic and improve the efficiency of interface processing.

[0037] For example, annotations can be used in entity classes to mark fields that need to be validated, and related interface endpoints can be associated with the annotations. In this way, before compiling the code and calling a certain interface, the parameter validation process will be performed first based on the annotations.

[0038] For example, annotations can be custom annotations as needed, which may include user-defined annotation content and corresponding bound validation rules.

[0039] S2. Determine the fields to be validated and the corresponding rule index information based on custom annotations.

[0040] Specifically, upon recognizing a custom annotation, the location of the field to be validated can be determined based on the annotation, and the input parameter (the field to be validated) can be obtained. Simultaneously, the corresponding rule index information can be retrieved based on the custom annotation. This rule index information can be the label or storage address of a specific validation rule, used to invoke the corresponding validation rule. One custom annotation corresponds to one field to be validated, and one custom annotation can correspond to one or more rule indexes, thus enabling the same field to be validated to be validated using one or more validation rules.

[0041] S3. Retrieve the corresponding target validation rule from the rule cache list based on the rule index information. The rule cache list is loaded and cached based on a dynamic rule base during compilation initialization or when rule changes occur.

[0042] For example, the dynamic rule base stores a variety of validation rules. These validation rules can be customized and changed at any time according to user needs. During compilation and initialization, the system can load a rule cache list based on the dynamic rule base. At the same time, when a rule change is detected in the dynamic rule base, the system will reload the rule cache list according to the changed dynamic rule base.

[0043] When calling validation rules based on annotations, the corresponding validation rules are retrieved from the rule cache list, eliminating the need to access the dynamic rule library, thereby reducing database access and enabling fast validation.

[0044] For example, based on the rule index information, the target validation rule corresponding to the current custom annotation can be obtained from the rule cache list.

[0045] S4. Validate the corresponding fields to be validated based on the target validation rules.

[0046] Finally, based on the obtained target validation rules, the validation process is implemented for the corresponding fields to be validated. If the validation passes, the process continues; if the validation fails, an exception is thrown.

[0047] Based on this, by adopting a validation method oriented towards cache rules, and dynamically adapting to business changes in the rule base, the efficiency of interface validation in dynamic business scenarios can be effectively improved and maintenance costs reduced.

[0048] In some embodiments, the interface verification method based on dynamic rules further includes: In response to a rule modification command, the target rule identifier and the corresponding rule update content are determined based on the rule modification command; wherein, the rule modification command is triggered when a change in the rule content of the dynamic rule base is detected; The rules in the rule cache list corresponding to the target rule identifier are updated based on the rule update content.

[0049] It should be noted that users can modify the validation rules in the dynamic rule base at any time according to their business needs.

[0050] For example, a change in rule content refers to a modification of an existing validation rule in the dynamic rule base, such as a threshold adjustment or a format adjustment.

[0051] When a change in rule content is detected in the dynamic rule base, a rule modification command is automatically triggered. This command includes the identifier of the changed validation rule (target rule identifier) ​​and the corresponding rule update content. Thus, when the rule modification command is triggered, the rule corresponding to the target rule identifier in the rule cache list can be identified simultaneously, and the rule can be updated based on the rule update content, thereby achieving a cache update of the rule cache list.

[0052] Based on this, by monitoring changes in the rule content of the dynamic rule base in real time and triggering timely updates to the rule cache list, the efficiency of interface verification is further improved.

[0053] In some embodiments, the interface verification method based on dynamic rules further includes: In response to business change instructions, the rule cache list is reloaded based on the current dynamic rule base; The business change instruction is triggered when a rule addition or deletion event is detected in the dynamic rule base.

[0054] Understandably, in addition to modifying the content of the validation rules in the dynamic rule base, users can also choose to add new validation rules or delete existing validation rules as needed.

[0055] When a rule addition or deletion event is detected in the dynamic rule base, a business change instruction is automatically triggered. In response to the business change instruction, the rule cache list can be reloaded, so that the rule cache list can be updated synchronously with the dynamic rule base.

[0056] Based on this, the reliability of interface verification is further improved by automatically reloading the rule cache list when a new or deleted rule is detected in the dynamic rule base.

[0057] In some embodiments, the interface verification method based on dynamic rules further includes: If a change event is detected in the rule cache list, the corresponding second target verification rule is retrieved from the changed rule cache list based on the rule index information; where the change event includes cache update or reload. The corresponding fields to be verified are verified based on the second target verification rule.

[0058] For example, when a change event is detected in the rule cache list, such as a cache update or reload, a re-verification process is automatically triggered.

[0059] Specifically, based on the rule index information corresponding to the custom annotation obtained previously, the corresponding verification rule (second target verification rule) can be retrieved again from the rule cache list. Then, the corresponding field to be verified can be re-verified based on the currently obtained second target verification rule.

[0060] Based on this, by automatically detecting changes in the rule cache table and automatically triggering the re-verification process, the reliability and efficiency of verification are further improved.

[0061] In some embodiments, the interface verification method based on dynamic rules further includes: Obtain the first verification result based on the target verification rule for the corresponding field to be verified; Obtain the second verification result based on the second target verification rule for the corresponding field to be verified; Difference location information is generated based on the comparison between the first verification result and the second verification result; wherein, the difference location information includes the field to be verified where the verification results differ, as well as its corresponding target verification rule and second target verification rule.

[0062] It should be noted that when the rule cache list changes and triggers re-verification, the first verification result before re-verification (verification based on the rule cache list before the change) can be obtained, which is the first verification result of the corresponding field to be verified based on the target verification rule; in addition, after re-verification, the second verification result of the corresponding field to be verified based on the second target verification rule can be obtained.

[0063] For example, the first verification result / second verification result may include whether the field passed verification, the reason for failure, or specific information about the failure. This allows for comparison of the first and second verification results, identifying which fields to be verified have inconsistent first and second verification results. When inconsistencies are found, corresponding difference location information can be generated. This difference location information includes the fields to be verified whose verification results differ, as well as the corresponding target verification rule (the corresponding verification rule before the rule cache list change) and the second target verification rule (the corresponding verification rule after the rule cache list change).

[0064] Based on this, by obtaining the difference location information between the two verifications before and after the update after updating the rule cache table and re-triggering the verification process, developers can quickly verify the rationality of the rule settings and the reliability of the verification, thereby further improving development efficiency.

[0065] In some embodiments, the interface verification method based on dynamic rules further includes: If a rule cache list change event is detected, and the corresponding validation rule cannot be obtained from the rule cache list after the change based on the rule index information, an annotation exception message will be issued. The annotation exception message includes the custom annotation information corresponding to the field to be validated.

[0066] It should be noted that when a rule cache list changes, before re-validation is triggered, there may be situations where the corresponding validation rule cannot be obtained based on the previously determined annotations. For example, if a validation rule is deleted from the dynamic rule library, after the rule cache list is synchronized and updated, the corresponding validation rule will not be able to be obtained from the updated rule cache list based on the previously determined rule index information.

[0067] In this situation, an annotation exception message can be triggered, which includes the custom annotation information corresponding to the field to be validated. This allows developers to quickly confirm whether adjustments need to be made to the custom annotation, such as modifying the rule index information mapped to the custom annotation, or whether modifications need to be made to the dynamic rule base, such as adding validation rules corresponding to the corresponding rule index information.

[0068] Based on this, if the target validation rule corresponding to the annotation index information cannot be obtained during the re-validation process after the rule cache list changes, an annotation exception prompt will be triggered, which can help users quickly confirm the exception and further improve development efficiency.

[0069] In some embodiments, the interface verification method based on dynamic rules further includes: If it is determined that a custom annotation has changed, retrieve the corresponding validation rules to be updated from the dynamic rule base; If the changes to the custom annotations meet the preset automatic update conditions, the validation rules to be updated are modified based on the changes to obtain the updated validation rules. The dynamic rule base is updated based on the updated validation rules.

[0070] It should be noted that when a change is detected in a custom annotation marked in an entity class, the corresponding validation rules can be automatically updated. Specifically, based on the currently changed custom annotation, the corresponding validation rules to be updated can be retrieved from the dynamic rule library according to its rule index information.

[0071] Then, based on the changes in the custom annotation compared to the previous annotation, it is determined whether the automatic update conditions are met. For example, if the modified mode is the same as the preset judgment mode, and only the verification threshold is modified, it is determined that the automatic update conditions are met. At this time, the verification rule to be updated can be modified directly based on the changed content (for example, modifying the threshold of the verification rule based on the value of the annotation change), forming the updated verification rule, and updating it to the dynamic rule base (for example, replacing the corresponding verification rule in the dynamic rule base).

[0072] Based on this, the efficiency of interface validation is further improved by determining whether to automatically update the validation rules according to the changes when annotations are modified.

[0073] In some embodiments, the corresponding fields to be validated are validated based on the target validation rules, including: The corresponding validation logic is determined based on custom annotations; The corresponding fields to be verified are verified according to the verification logic and the target verification rules.

[0074] It should be noted that when adding annotations, you can also specify custom validation logic according to your needs. For example, when there are multiple validation steps in the corresponding validation rule, you can specify the corresponding validation order.

[0075] In this way, after obtaining the validation rules, validation processing can be performed on the corresponding fields to be validated based on the specified validation logic.

[0076] Based on this, by determining the corresponding validation logic according to the annotations and implementing interface validation according to specific validation logic, the flexibility of interface validation is further improved.

[0077] In some embodiments, the dynamic rule base includes basic validation rules and combined validation rules; wherein, the basic validation rules include at least one of regular expression validation rules, range threshold validation rules, and format validation rules, and the combined validation rules are validation rules that combine multiple basic validation rules using logical operators.

[0078] It should be noted that the dynamic rule base can include two types of verification rules: basic verification rules and combined verification rules. Basic verification rules refer to verification rules consisting of only a single verification action, while combined verification rules refer to verification rules formed by combining multiple (two or more) basic verification rules (i.e., multiple verification actions).

[0079] The basic validation rules may include one or more of the following: regular expression validation rules, range threshold validation rules, and format validation rules.

[0080] Based on this, by setting up various basic validation rules that support regular expressions, range thresholds, and format validation, as well as validation rules that combine various basic validation rules using logical operators, the flexibility of validation is further improved.

[0081] The implementation process of the proposed solution is described in detail below: This example provides a fast interface validation method based on a dynamic rule engine. The implementation of this method mainly includes the following parts: First, the custom rules module.

[0082] Custom rules (such as regular expressions, range thresholds, and format validation (e.g., email) can be maintained through a visual interface. Multiple rules can be combined using logical operators (such as AND / OR / NOT), and associated with API endpoints. These rules are then stored in a database or file, and the validation logic is loaded in real-time using Groovy scripts. Before the API call stores the data in the database or file, parameter validation is performed using an interceptor (ApiValidationInterceptor) to prevent invalid business logic execution and improve API processing efficiency.

[0083] Specifically, a simple rule class can be defined, and then GroovyShell can be used to dynamically create and manipulate these rules. The context variables can be passed using GroovyShell's Binding object to achieve dynamic binding between rules and data.

[0084] Then, a dynamic rule base common_script is created. The fields of the rules include the primary key identifier id, the ruleKey unique identifier, the templateScript script, and the target_class class name.

[0085] By creating the GroovyScriptVar class, a dynamic rule base is queried and validation rules are cached when the project starts, for example, by storing them in a ConcurrentHashMap (a list of cached rules). Cached validation rules through this mechanism reduce database access and enable faster validation.

[0086] It's worth noting that the GroovyScriptVar class provides a method to refresh scripts (by uniquely identifying them using the ruleKey and re-adding them to the rule cache list). This allows you to reload rule scripts when business logic changes, avoiding service restarts. When modifying rules in the dynamic rule base using a custom rule module, GroovyShell can be used to dynamically modify and query rules.

[0087] Additionally, you can create the `invokeGroovyMethod` method to execute a specified method in a Groovy script and return the result. The parameters include the Groovy script string to be executed, the name of the method to be called, etc. The parameter array passed to the method is as follows: / ** * Executes the specified method in the Groovy script and returns the result.

[0088] * * @param templateScript / / The Groovy script string to be executed.

[0089] * @param methodName / / The name of the method to be called.

[0090] * @param params / / The array of parameters passed to the method.

[0091] * @return / / The result of the method execution.

[0092] * @throws Exception / / If the method call fails or other exceptions occur.

[0093] / The `invokeGroovyMethod` method described above directly returns a standardized error response when validation fails, reducing interface processing overhead. This implementation tightly integrates the dynamic rule engine with the interface request processing flow, ensuring efficient execution and flexible configuration of the validation logic, fully reflecting the application scenario characteristics of "fast interface validation".

[0094] Second: Define a custom annotation.

[0095] Create a custom annotation DynamicRule, which can be used to mark the fields that need to be validated and their corresponding rule indexes.

[0096] Third: Create a custom validator.

[0097] Create a RuleManager class that implements ConstraintValidator to manage these custom rules and dynamically apply them based on annotations.

[0098] Specifically, you can use the `initialize()` method to iterate through all the declared fields of an object and check if they have the `@DynamicRule` annotation.

[0099] If the field has an annotation, the corresponding validation rule script value templateScript is obtained from the ConcurrentHashMap of the GroovyScriptVar class in the first part based on the ruleKey (rule index) of the annotation.

[0100] During rule validation, script validation logic can be executed in the `isValid` method. If it's a SPEL expression, it will be executed directly. If a method needs to be called, such as the script `def methodName(config) { return 'Execution result: ' +config}`, then the `invokeGroovyMethod` method will be called to return the output. Additionally, specific validation logic can be added for different rule keys as needed.

[0101] Fourth: Use annotations in entity classes.

[0102] Finally, you can use the @DynamicRule annotation in a class to mark the fields that need to be validated, and then use RuleManager to validate the target field object.

[0103] The following are specific examples to illustrate this: 1. First, maintain custom rules through a visual interface and store them in the dynamic rule library common_script.

[0104] Example 1 of dynamic rule base validation rules: / / Used to validate that the string length of the PASSWORD_RULE annotation is greater than 5.

[0105] "ruleKey": "PASSWORD_RULE", "templateScript'": "{ value ->value instanceof String&&value.length()>5}" , "target_class": "UserDTO".

[0106] When business requirements change, the validation rule in Example 1 of the dynamic rule base can be modified to: the string length of the PASSWORD_RULE annotation is greater than 5 and the validation password value is a combination of uppercase letters, etc. The rule can be modified using the logical operator AND through the custom interface. "templateScript'": "{ value ->value instanceof String&&value.length()>5 AND ^(?=.*[AZ])(?=.*\\d)(?=.*[$#@!])[\\w$#@!]{10,}$}". / / The string must be at least 5 characters long and contain at least one uppercase letter, one digit, and one special character ($#@!).

[0107] Here, (?=.*[AZ]) is a positive lookahead, indicating that the string must contain at least one uppercase letter. (?=.*\\d) is a positive lookahead, indicating that the string must contain at least one digit. (?=.*[$#@!]) is a positive lookahead, indicating that the string must contain at least one special character ($, #, @, or !).

[0108] Example 2 of dynamic rule base validation rules: / / Used to determine whether the execution method has been completed.

[0109] "ruleKey": "US", "templateScript'": "def methodName(config) { return 'Execution result: ' +config}", "target_class": "UserDTO".

[0110] / / Creation method methodName function methodName (int status){ if ("COMPLETED" == status) { / / If the condition is COMPLETED, return "Condition is complete".} else { return "Condition is not complete".} } It's worth noting that when validation rules change, the GroovyScriptVar class can be called to refresh the cached rule scripts. This allows the scripts to be reloaded when business logic changes, avoiding a service restart. When modifying rules through the custom rule module, GroovyShell can be used to dynamically modify and query the rules.

[0111] 2. Define a custom annotation.

[0112] Create a custom annotation DynamicRule to mark the fields that need to be validated and their rules.

[0113] @interface DynamicRule { String ruleKey() } Finally, you can use the @DynamicRule annotation in a class to mark the fields that need to be validated, and use the RuleManager to validate the object.

[0114] / / Dynamic solution implementation class UserDTO{ @DynamicRule(ruleKey = "PASSWORD_RULE") String password @DynamicRule(ruleKey = "US") String valuetest } / / Example 1 of application validation rules UserDTO user = new UserDTO(password: "1234") / / This user's password "1234" will not pass the verification (because it is not long enough).

[0115] RuleManager.isValid(user) / / Should be false because it does not meet the validation condition of rule "1234" (insufficient length).

[0116] / / Example 2 of application validation rules: UserDTO valuetest= new UserDTO(valuetest: "COMPLETED") / / RuleManager.isValid(valuetest) / / Output: Execution result: The condition is complete. It should be noted that, based on the four steps described above, dynamic validation rules for objects are implemented using Groovy annotations and dynamic features. This method is well-suited for scenarios requiring dynamic adjustment of validation logic based on runtime data. Furthermore, RuleManager can be extended to support more complex validation logic and various types of validation rules as needed.

[0117] As can be seen from the above technical approach, the embodiments of this application systematically innovate from three levels: rule storage, loading mechanism, and execution engine, breaking through the limitations of static rule validation of Bean Validation, and realizing flexible configuration of validation logic through dynamic script extension.

[0118] Compared with the prior art, the embodiments of this application have the following beneficial effects: 1) It supports modifying the verification rules at any time during operation and enabling quick re-verification without restarting the service, thus reducing development costs and running time.

[0119] 2) Specific validation logic can be added to different rules, which can be applied to a variety of scenarios.

[0120] 3) Supports combining multiple validation rules using logical operators (AND / OR / NOT) to cover complex business scenarios.

[0121] Please refer to Figure 2 , Figure 2 The diagram illustrates a block diagram of a dynamic rule-based interface verification device provided in some embodiments of this application. It should be understood that this dynamic rule-based interface verification device is similar to the one described above. Figure 1 Corresponding to the method embodiments, it is able to execute the various steps involved in the above method embodiments. The specific functions of the interface verification device based on dynamic rules can be found in the description above. To avoid repetition, detailed descriptions are appropriately omitted here.

[0122] Figure 2 The dynamic rule-based interface verification device includes at least one software function module that can be stored in a memory or embedded in the dynamic rule-based interface verification device in the form of software or firmware. The dynamic rule-based interface verification device includes: The annotation acquisition module 210 is used to acquire custom annotations associated with the interface before calling the interface for processing. Information determination module 2220 is used to determine the fields to be verified and the corresponding rule index information based on custom annotations; The rule acquisition module 230 is used to retrieve the corresponding target verification rule from the rule cache list based on the rule index information; wherein, the rule cache list is loaded and cached based on the dynamic rule library when the compilation is initialized or when rule changes occur; The field validation module 240 is used to validate the corresponding fields to be validated based on the target validation rules.

[0123] It is understood that the above-described device embodiments correspond to the method embodiments of the present invention. The interface verification device based on dynamic rules provided by the embodiments of the present invention can implement the interface verification method based on dynamic rules provided by any one of the method embodiments of the present invention.

[0124] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the aforementioned method, and will not be elaborated further here.

[0125] like Figure 3 As shown, some embodiments of this application provide an electronic device 300, which includes: a memory 310, a processor 320, and a computer program stored in the memory 310 and executable on the processor 320. When the processor 320 reads the program from the memory 310 via a bus 330 and executes the program, it can implement any of the methods included in the above-described interface verification method based on dynamic rules.

[0126] Processor 320 can process digital signals and may include various computing architectures. For example, it may be a complex instruction set computer architecture, a reduced instruction set computer architecture, or an architecture that implements multiple instruction set combinations. In some examples, processor 320 may be a microprocessor.

[0127] The memory 310 can be used to store instructions executed by the processor 320 or data related to the execution of instructions. These instructions and / or data may include code used to implement some or all of the functions of one or more modules described in the embodiments of this application. The processor 320 of this disclosure embodiment can be used to execute the instructions in the memory 310 to implement the methods shown above. The memory 310 includes dynamic random access memory, static random access memory, flash memory, optical memory, or other memories well known to those skilled in the art.

[0128] Some embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, describes the method described in the method embodiments.

[0129] Some embodiments of this application also provide a computer program product that, when run on a computer, causes the computer to perform the methods described in the method embodiments.

[0130] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0131] It should be understood, in the several embodiments provided in this application, that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0132] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0133] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0134] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0135] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0136] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. An interface verification method based on dynamic rules, characterized in that, include: Before calling the interface, obtain the custom annotations associated with the interface; Based on the custom annotation, determine the fields to be verified and the corresponding rule index information; The corresponding target verification rule is retrieved from the rule cache list based on the rule index information; wherein, the rule cache list is loaded and cached based on a dynamic rule library when the compilation is initialized or when rule changes occur; The corresponding fields to be verified are verified based on the target verification rules.

2. The interface verification method based on dynamic rules according to claim 1, characterized in that, Also includes: In response to a rule modification instruction, a target rule identifier and corresponding rule update content are determined based on the rule modification instruction; wherein, the rule modification instruction is triggered when a rule content change is detected in the dynamic rule base; Based on the rule update content, the rules corresponding to the target rule identifier in the rule cache list are cached and updated.

3. The interface verification method based on dynamic rules according to claim 1, characterized in that, Also includes: In response to a business change instruction, the rule cache list is reloaded based on the current dynamic rule base; The business change instruction is triggered when a rule addition or deletion event is detected in the dynamic rule base.

4. The interface verification method based on dynamic rules according to claim 1, characterized in that, Also includes: If a change event is detected in the rule cache list, the corresponding second target verification rule is retrieved from the changed rule cache list based on the rule index information; wherein, the change event includes cache update or reload; The corresponding fields to be verified are verified based on the second target verification rule.

5. The interface verification method based on dynamic rules according to claim 4, characterized in that, Also includes: Obtain the first verification result of the corresponding field to be verified based on the target verification rule; Obtain the second verification result based on the second target verification rule for the corresponding field to be verified; Difference location information is generated based on the comparison between the first verification result and the second verification result; wherein, the difference location information includes the fields to be verified where the verification results differ, their corresponding target verification rules, and the second target verification rule.

6. The interface verification method based on dynamic rules according to claim 4, characterized in that, Also includes: If a change event is detected in the rule cache list, and the corresponding verification rule cannot be obtained from the rule cache list after the change based on the rule index information, an annotation exception message is issued; wherein, the annotation exception message includes custom annotation information corresponding to the field to be verified.

7. The interface verification method based on dynamic rules according to claim 1, characterized in that, Also includes: If it is determined that the custom annotation has changed, the corresponding verification rule to be updated is obtained from the dynamic rule base; If the changes to the custom annotation meet the preset automatic update conditions, the verification rules to be updated are modified based on the changes to obtain the updated verification rules. The dynamic rule base is updated based on the updated verification rules.

8. The interface verification method based on dynamic rules according to claim 1, characterized in that, The step of validating the corresponding fields to be validated based on the target validation rule includes: The corresponding validation logic is determined based on the custom annotation. According to the verification logic, the corresponding fields to be verified are verified based on the target verification rules.

9. The interface verification method based on dynamic rules according to any one of claims 1 to 8, characterized in that, The dynamic rule base includes basic validation rules and combined validation rules; wherein, the basic validation rules include at least one of regular expression validation rules, range threshold validation rules, and format validation rules, and the combined validation rules are validation rules that combine multiple basic validation rules using logical operators.

10. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it can implement the interface verification method based on dynamic rules as described in any one of claims 1-9.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, performs the interface verification method based on dynamic rules as described in any one of claims 1-9.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the interface verification method based on dynamic rules as described in any one of claims 1-9.

Images