Multiplexed verification method for API interface verification

Abstract

The invention discloses a multiplexing verification method for API interface verification, relates to the field of computer processing, and comprises the following steps: constructing a verification database, and forming a corresponding protoc plug-in according to the verification database; obtaining a protoc file, and parsing the corresponding protoc file based on the obtained protoc plug-in to obtain a corresponding verification structure; constructing a registration function, and registering the obtained verification option structure in the protoc plug-in based on the constructed registration function; traversing the corresponding registration function to construct a corresponding string variable; constructing a corresponding black and white list file based on the obtained string variable; generating a corresponding verification code based on the obtained black and white list file, and performing multiplexing verification on the corresponding API interface verification based on the verification code; the invention is beneficial to improving the verification efficiency.

Description

Technical Field

[0001] The present invention relates to the field of computer processing, and in particular to a multiplexing verification method for API interface verification. Background Art

[0002] Traditional protobuf interface verification only supports verification of specific structures. If 100 interfaces need to use the same structure, and each interface may require or not require fields in the structure, the traditional method requires repeatedly defining the same structure in 100 interfaces and filling in verification rules for each structure.

[0003] Compared with existing technologies, existing verification methods often write verification logic for each API separately, resulting in high code duplication and increased maintenance costs. When the verification rules change, the verification code of each API needs to be modified one by one, which is inefficient. These are the problems we need to solve. To this end, we provide a reused verification method for API interface verification. Summary of the Invention

[0004] The purpose of the present invention is to provide a multiplexing verification method for API interface verification.

[0005] The purpose of the present invention can be achieved by the following technical solution: a multiplexing verification method for API interface verification, comprising the following steps:

[0006] Step 1: Build a verification database and build the corresponding protoc plug-in based on the verification database;

[0007] Step 2: Get the protoc file, and parse the corresponding protoc file based on the obtained protoc plug-in to obtain the corresponding verification structure;

[0008] Step 3: Build a registration function, and based on the built registration function, register the obtained verification option structure into the protoc plug-in;

[0009] Step 4: Traverse the corresponding registration function and construct the corresponding string variable;

[0010] Step 5: Construct the corresponding blacklist and whitelist file based on the obtained string variable;

[0011] Step 6: Generate corresponding verification codes based on the obtained blacklist and whitelist files, and perform multiplexing verification on the corresponding API interface verification based on the verification codes.

[0012] Furthermore, the process of building a verification database and establishing a corresponding protoc plug-in based on the verification database includes:

[0013] A data acquisition unit is provided, wherein the data acquisition unit is used to collect data on parameter verification requirements of different types of API interfaces, obtain corresponding verification data, and build a corresponding verification database based on the obtained verification data;

[0014] Set up a monitoring node, which is used to collect interface information of the target API interface and obtain corresponding API interface data;

[0015] Based on the obtained verification database and interface data, corresponding verification strategies are set for all field types in the target API interface verification process, and based on the obtained verification strategies, corresponding protoc plug-ins are established, and the protoc plug-in is internally provided with a parser and a verification code generator.

[0016] Furthermore, the protoc file is obtained, and the corresponding protoc file is parsed based on the obtained protoc plug-in to obtain the corresponding verification structure. The process includes:

[0017] Get the protoc file and pass it to the protoc plug-in in the form of a binary stream;

[0018] When the protoc plug-in receives the binary stream, it identifies the field type in the corresponding binary stream according to the field definition, selects the corresponding type parser according to the field type, and parses the corresponding binary stream into the built-in type template inside the corresponding protoc plug-in according to the type parser;

[0019] After the parsing is completed, the corresponding parsing results are obtained and stored in the option structure inside the corresponding protoc plug-in;

[0020] Based on the obtained option structure, a check option structure named RCheckOptions is defined in the parser. The check option structure RCheckOptions includes array fields In and NotIn of string type.

[0021] Furthermore, the process of constructing a registration function and registering the obtained verification option structure in the protoc plug-in based on the constructed registration function includes:

[0022] Construct a corresponding registration function based on the check option structure RCheckOptions, which accepts a pointer to map[string]RCheckOptions as a parameter;

[0023] Read the obtained registration function, obtain two dictionary variables of the map type in the corresponding registration function, and record them as mapIn and mapNotIn;

[0024] Assign the values ​​of the corresponding map[string]RCheckOptions to mapIn and mapNotIn respectively. After the assignment is completed, obtain the field attributes corresponding to the registered option structure in the check option structure RCheckOptions, combine the structure name and field attribute name into the format of "structure name.field attribute name", and add it as a key to mapIn and mapNotIn;

[0025] After the addition is completed, call the corresponding registration function to register the corresponding check option structure RCheckOptions into the protoc plug-in.

[0026] Furthermore, the process of traversing the corresponding registration function and constructing the corresponding string variable includes:

[0027] Set blank string variables, which are string type variables strIn and strNotIn, to store formatted strings;

[0028] Traverse each item in mapIn and mapNotIn in the corresponding registration function based on a for loop, wherein the item includes a key and a pair;

[0029] After the traversal is completed, each item in the corresponding mapIn and mapNotIn is formatted as "key": {}; after the formatting is completed, the corresponding formatted string is appended to the corresponding strIn and strNotIn respectively; and the corresponding string variable is obtained.

[0030] Furthermore, the process of constructing a corresponding blacklist and whitelist file based on the obtained string variable includes:

[0031] Construct the corresponding Check function based on mapIn, mapNotIn and the string representing the structure field as the accepted parameters;

[0032] The Check function splits the string of the input structure field to obtain the corresponding structure name and field attribute name, and searches for the corresponding combination of structure name and field attribute name in the corresponding mapIn and mapNotIn based on it;

[0033] If it exists in mapIn, it returns true; if it exists in mapNotIn, it returns false; if it does not exist in both mapIn and mapNotIn, it returns a default value or throws an exception based on actual needs;

[0034] Read the corresponding return result. If the return type of the result is Boolean, then the corresponding field is a whitelist field. If it is not a Boolean type, then it is a blacklist field.

[0035] The blacklist field and whitelist field obtained by statistics are used to classify and identify the contents of strIn and strNotIn in the string variable, and generate corresponding blacklist and whitelist files based on the classification and identification results. The blacklist and whitelist files include a blacklist file and a whitelist file.

[0036] Furthermore, a corresponding verification code is generated based on the obtained blacklist and whitelist file, and a corresponding API interface verification is multiplexed based on the verification code. The verification process includes:

[0037] Read the obtained parsing result, and obtain the field type corresponding to each field in the corresponding binary stream according to the parsing result; read the obtained field type and set the corresponding code template for it;

[0038] The Check function is integrated into the constructed code template. The Check function is used to check whether the field in the corresponding template belongs to the blacklist or whitelist file. If it belongs to the blacklist file, no verification code needs to be generated. If it belongs to the whitelist file, the code template and field attributes corresponding to the corresponding field are input into the verification code generator to obtain the corresponding verification code.

[0039] Obtain corresponding verification data based on the target API interface data, the verification data including ID, request data and return data;

[0040] The ID in the corresponding verification data is verified based on the hash algorithm. If the verification fails, the verification process of the corresponding API interface is terminated; if the verification passes, the corresponding return data is matched based on the obtained verification code. If the match is successful, a verification success notification is returned; if the match fails, a verification failure notification is returned, and detailed information about the failure is returned.

[0041] Compared with the prior art, the present invention has the following beneficial effects:

[0042] 1. By building a verification database and corresponding plug-ins, you can achieve fast and accurate verification of API interface parameters; avoid the traditional manual verification method, greatly improve verification efficiency, and reduce the possibility of errors;

[0043] 2. The use of reused verification methods eliminates the need for developers to write verification code for each API interface, thereby reducing development costs. At the same time, since the verification strategy is encapsulated in the plug-in, the workload of subsequent maintenance is also reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 This is a schematic diagram of the present invention. DETAILED DESCRIPTION

[0045] like Figure 1 As shown, the multiplexing verification method for API interface verification includes the following steps:

[0046] Step 1: Build a verification database and build the corresponding protoc plug-in based on the verification database;

[0047] Step 2: Get the protoc file, and parse the corresponding protoc file based on the obtained protoc plug-in to obtain the corresponding verification structure;

[0048] Step 3: Build a registration function, and based on the built registration function, register the obtained verification option structure into the protoc plug-in;

[0049] Step 4: Traverse the corresponding registration function and construct the corresponding string variable;

[0050] Step 5: Construct the corresponding blacklist and whitelist file based on the obtained string variable;

[0051] Step 6: Generate corresponding verification codes based on the obtained blacklist and whitelist files, and perform multiplexing verification on the corresponding API interface verification based on the verification codes;

[0052] It should be further explained that, in the specific implementation process, the process of building a verification database and establishing the corresponding protoc plug-in based on the verification database includes:

[0053] A data acquisition unit is provided, which is used to collect data on parameter verification requirements of different types of API interfaces, obtain corresponding verification data, and build a corresponding verification database based on the obtained verification data. The verification database includes multiple verification rules such as data type verification, data range verification, and data format verification;

[0054] Set up a monitoring node, which is deployed at the target API interface and is used to collect interface information of the target API interface and obtain corresponding API interface data, which includes but is not limited to URL, Method, type of request data, and type of return data;

[0055] Setting corresponding verification strategies for all field types in the target API interface verification process based on the obtained verification database and interface data, wherein the verification strategies include selecting and combining different verification rules;

[0056] Furthermore, a corresponding protoc plug-in is constructed based on the obtained verification strategy. The protoc plug-in is internally provided with a parser and a verification code generator, wherein the parser is used to parse the binary stream into the corresponding field type; the verification code generator is used to generate the corresponding verification code according to the parsed field type.

[0057] It should be further explained that, in the specific implementation process, the process of obtaining the protoc file and parsing the corresponding protoc file based on the obtained protoc plug-in to obtain the corresponding verification structure includes:

[0058] Get the protoc file, and receive the corresponding protoc file through the interface function in the corresponding protoc plug-in, wherein the interface function receives binary data as a parameter, that is, the corresponding protoc plug-in receives the binary stream from the protoc file;

[0059] When the protoc plug-in receives the binary stream, it identifies the field type in the corresponding binary stream according to the field definition, selects the corresponding type parser according to the field type, and parses the corresponding binary stream into the built-in type template inside the corresponding protoc plug-in according to the type parser, wherein the built-in type template is used to map the field type of the binary stream; for example: for basic types such as int32, float, double, string, etc., the protoc plug-in has a corresponding parsing function; for more complex types, such as enumeration types, nested types, array types, etc., the protoc plug-in can also select the corresponding type parser for parsing;

[0060] After the parsing is completed, the corresponding parsing results are obtained, which include but are not limited to message definitions, field information, and nested types; the corresponding parsing results are stored in the option structure inside the corresponding protoc plug-in, wherein the data structure is used to reflect the data structure defined in the protoc file, and the data structure includes the name, type, and value of the field;

[0061] Furthermore, based on the obtained option structure, a check option structure named RCheckOptions is defined in the parser, wherein the check option structure RCheckOptions contains array fields In and NotIn of string type; wherein the parsing result will eventually be used to fill the In and NotIn arrays in the check option structure RCheckOptions;

[0062] It should be further explained that, in the specific implementation process, when parsing the protoc file, the extended information of the corresponding protoc file will be parsed synchronously, and the relevant information of the extended attributes will be recorded in the In and NotIn arrays.

[0063] It should be further explained that, in the specific implementation process, the process of constructing a registration function and registering the obtained verification option structure in the protoc plug-in based on the constructed registration function includes:

[0064] Construct a corresponding registration function based on the check option structure RCheckOptions. The registration function accepts a pointer to map[string]RCheckOptions as a parameter, which is used to store the structure name and the corresponding check option structure RCheckOptions.

[0065] Read the obtained registration function, obtain two dictionary variables of the map type in the corresponding registration function, and record them as mapIn and mapNotIn; where the dictionary key is of string type and the value is of empty struct type; the mapIn is used to store the required field verification options, and the mapNotIn is used to store the non-required field verification options;

[0066] Assign the corresponding map[string]RCheckOptions values ​​to mapIn and mapNotIn respectively, that is, mapIn and mapNotIn will reference the same memory address, so that the same data can be accessed and modified;

[0067] After the assignment is completed, obtain the field attributes corresponding to the registered option structure in the check option structure RCheckOptions, combine the structure name and field attribute name into the format of "structure name.field attribute name", and add it as a key to mapIn and mapNotIn;

[0068] After the addition is completed, call the corresponding registration function to register the corresponding check option structure RCheckOptions into the protoc plug-in.

[0069] It should be further explained that, in the specific implementation process, the process of traversing the corresponding registration function and constructing the corresponding string variable includes:

[0070] Set blank string variables, which are string type variables strIn and strNotIn, to store formatted strings;

[0071] Based on the for loop, each item in mapIn and mapNotIn in the corresponding registration function is traversed respectively. The item includes a key and a pair, where the key represents the combination of the structure name and the field attribute name, and the value represents the corresponding check option structure RCheckOptions;

[0072] After the traversal is completed, each item in the corresponding mapIn and mapNotIn is formatted as "key":{}, where key is the key of the item and {} indicates that the value of the check option structure RCheckOptions will be further processed (for example, converted to JSON format).

[0073] After formatting is completed, append the corresponding formatted strings to the corresponding strIn and strNotIn respectively; obtain the corresponding string variables;

[0074] It should be further explained that, during implementation, if the appended strIn and strNotIn are not empty, a comma or other separator must be added before the new item to conform to the JSON array format. During formatting, special characters such as quotation marks and backslashes must be handled carefully to ensure that the final string is in a valid JSON format.

[0075] It should be further explained that, in a specific implementation process, the process of constructing a corresponding blacklist and whitelist file based on the obtained string variable includes:

[0076] Construct the corresponding Check function based on mapIn, mapNotIn and a string representing a structure field as accepted parameters, where the format of the string is "structure name.field attribute name";

[0077] The Check function splits the string of the input structure field to obtain the corresponding structure name and field attribute name, and searches for the corresponding combination of structure name and field attribute name in the corresponding mapIn and mapNotIn based on it;

[0078] If it exists in mapIn, it returns true; if it exists in mapNotIn, it returns false; if it does not exist in both mapIn and mapNotIn, it returns a default value or throws an exception based on actual needs;

[0079] Read the corresponding return result. If the return type of the result is Boolean, then the corresponding field is a whitelist field. If it is not a Boolean type, then it is a blacklist field.

[0080] Furthermore, the obtained blacklist fields and whitelist fields are statistically classified to identify the contents of strIn and strNotIn in the string variable, and corresponding blacklist and whitelist files are generated based on the classification and identification results. The blacklist and whitelist files include blacklist files and whitelist files.

[0081] It should be further explained that, in the specific implementation process, the corresponding verification code is generated based on the obtained blacklist and whitelist file, and the corresponding API interface verification is multiplexed based on the verification code. The verification process includes:

[0082] Read the obtained parsing result, and obtain the field type corresponding to each field in the corresponding binary stream according to the parsing result. The field type includes but is not limited to int64, string, bool, and custom message type;

[0083] Read the obtained field type and set the corresponding code template for it. For example, the checksum of int64 type is mapped to the int64 template, and the checksum of string type is mapped to the string template.

[0084] The Check function is integrated into the constructed code template. The Check function is used to check whether the field in the corresponding template belongs to the blacklist or whitelist file. If it belongs to the blacklist file, no verification code needs to be generated. If it belongs to the whitelist file, the code template and field attributes corresponding to the corresponding field are input into the verification code generator to obtain the corresponding verification code.

[0085] Then, based on the target API interface data, corresponding verification data is obtained, wherein the verification data includes an ID, request data, and return data;

[0086] The ID in the corresponding verification data is verified based on the hash algorithm. If the verification fails, the verification process of the corresponding API interface is terminated; if the verification passes, the corresponding return data is matched based on the obtained verification code. If the match is successful, a verification success notification is returned; if the match fails, a verification failure notification is returned, and detailed information about the failure is returned.

[0087] The above embodiments are only used to illustrate the technical method of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical method of the present invention may be modified or replaced by equivalents without departing from the spirit and scope of the technical method of the present invention.

Claims

1. A multiplexing verification method for API interface verification, characterized in that: The following steps are involved: Step 1: Build a verification database and build the corresponding protoc plug-in based on the verification database: A data collection unit is provided, wherein the data collection unit is used to collect data on parameter verification requirements of different types of API interfaces, obtain corresponding verification data, and build a corresponding verification database based on the obtained verification data; Set up a monitoring node, which is used to collect interface information of the target API interface and obtain corresponding API interface data; Based on the obtained verification database and interface data, corresponding verification strategies are set for all field types in the target API interface verification process, and based on the obtained verification strategies, corresponding protoc plug-ins are built, wherein the protoc plug-in is internally provided with a parser and a verification code generator; The parser is used to parse the binary stream into corresponding field types; the check code generator is used to generate corresponding check codes according to the parsed field types; Step 2: Get the protoc file, and parse the corresponding protoc file based on the obtained protoc plug-in to obtain the corresponding verification option structure; Step 3: Construct a registration function, and based on the constructed registration function, register the obtained verification option structure into the protoc plug-in; Step 4: Traverse the registration function and construct the corresponding string variable; Step 5: Construct the corresponding blacklist and whitelist file based on the obtained string variable; Step 6: Generate corresponding verification codes based on the obtained blacklist and whitelist files, and perform multiplexing verification on corresponding API interface verification based on the verification codes.

2. The multiplexing verification method for API interface verification according to claim 1 is characterized in that: The process of obtaining the protoc file and parsing the corresponding protoc file based on the obtained protoc plug-in to obtain the corresponding verification structure includes: Get the protoc file and pass it to the protoc plug-in in the form of a binary stream; When the protoc plug-in receives the binary stream, it identifies the field type in the corresponding binary stream according to the field definition, selects the corresponding type parser according to the field type, and parses the corresponding binary stream into the built-in type template inside the corresponding protoc plug-in according to the type parser; After the parsing is completed, the corresponding parsing results are obtained and stored in the option structure inside the corresponding protoc plug-in; Based on the obtained option structure, a check option structure named RCheckOptions is defined in the parser, and the check option structure RCheckOptions includes array fields In and NotIn of string type.

3. The multiplexing verification method for API interface verification according to claim 2 is characterized in that: The process of building a registration function and registering the obtained verification option structure in the protoc plug-in based on the built registration function includes: Construct a corresponding registration function based on the check option structure RCheckOptions, wherein the registration function accepts a pointer to map[string]RCheckOptions as a parameter; Read the obtained registration function, obtain two dictionary variables of the map type in the corresponding registration function, and record them as mapIn and mapNotIn; Assign the corresponding map[string]RCheckOptions values ​​to mapIn and mapNotIn respectively. After the assignment is completed, obtain the field attributes corresponding to the registered option structure in the check option structure RCheckOptions, combine the structure name and the field attribute name into the format of "structure name.field attribute name", and add it as a key to mapIn and mapNotIn; After the addition is completed, call the corresponding registration function to register the corresponding check option structure RCheckOptions into the protoc plug-in.

4. The multiplexing verification method for API interface verification according to claim 3 is characterized in that: The process of traversing the corresponding registered functions and constructing the corresponding string variables includes: Set blank string variables, which are string type variables strIn and strNotIn, for storing formatted strings; Based on the for loop, each item in mapIn and mapNotIn in the corresponding registration function is traversed respectively, and the item includes a key and a pair; After the traversal is completed, for each item in the corresponding mapIn and mapNotIn, format it into the form of "key": {}; after the formatting is completed, append the corresponding formatted string to the corresponding strIn and strNotIn respectively; obtain the corresponding string variable.

5. The multiplexing verification method for API interface verification according to claim 4 is characterized in that: The process of building the corresponding blacklist and whitelist file based on the obtained string variable includes: Construct the corresponding Check function based on mapIn, mapNotIn and the string representing the structure field as the accepted parameters; The Check function splits the string of the input structure field to obtain the corresponding structure name and field attribute name, and searches for the corresponding combination of structure name and field attribute name in the corresponding mapIn and mapNotIn based on the structure name and field attribute name. If it exists in mapIn, it returns true; if it exists in mapNotIn, it returns false; if it does not exist in both mapIn and mapNotIn, it returns a default value or throws an exception based on actual needs; Read the corresponding return result. If the return type of the return result is Boolean, then the corresponding field is a whitelist field. If it is not a Boolean type, then it is a blacklist field. The blacklist field and the whitelist field obtained by statistics classify and identify the contents in strIn and strNotIn in the string variable, and generate corresponding blacklist and whitelist files based on the classification and identification results. The blacklist and whitelist files include blacklist files and whitelist files.

6. The multiplexing verification method for API interface verification according to claim 5 is characterized in that: Generate corresponding verification codes based on the obtained blacklist and whitelist files, and perform multiplexing verification on corresponding API interfaces based on the verification codes. The verification process includes: Read the obtained parsing result, and obtain the field type corresponding to each field in the corresponding binary stream according to the parsing result; read the obtained field type and set a corresponding code template for it; The Check function is integrated into the constructed code template. The Check function is used to check whether the field in the corresponding template belongs to the blacklist or whitelist file; if it belongs to the blacklist file, there is no need to generate a verification code. If it belongs to the whitelist file, the code template and field attributes corresponding to the corresponding field are input into the verification code generator to obtain the corresponding verification code; Obtain corresponding verification data based on the target API interface data, wherein the verification data includes ID, request data and return data; The ID in the corresponding verification data is verified based on the hash algorithm. If the verification fails, the verification process of the corresponding API interface is terminated; if the verification passes, the corresponding return data is matched based on the obtained verification code. If the match is successful, a verification success notification is returned; if the match fails, a verification failure notification is returned, and detailed information on the failure is returned.

Images