Method and device for automatically generating a debugging request message based on API metadata

Abstract

The application discloses an API metadata-based automatic generation method and device for a debugging request message, and relates to the field of data processing. The method comprises the following steps: obtaining an API identifier, and querying API parameter metadata from a target database according to the API identifier; converting the API parameter metadata from a flat structure into a tree structure with hierarchical relationships, and classifying parameters with the same parent identifier into corresponding hierarchical nodes; constructing a debugging request message based on the tree structure; creating a nested mapping structure for an object type parameter in the debugging request message, creating a list structure for an array type parameter in the debugging request message, and filling a preset debugging default value for a basic type parameter in the debugging request message according to the parameter type, so as to obtain a debugging request message after parameter adjustment; and converting the debugging request message after parameter adjustment into a JSON format and returning the debugging request message to a client. The application can effectively reduce manual errors and improve development efficiency.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of data processing, and in particular to a method and device for automatically generating a debugging request message based on API metadata. BACKGROUND

[0002] With the widespread application of microservice architecture and RESTful API, API interfaces have become an indispensable part of modern software systems. In the software development life cycle, API interface debugging is a key link to ensure the correctness and stability of system functions. Developers need to construct various test requests to verify the input-output behavior, boundary condition handling and exception response of the API. However, modern API interfaces often have complex parameter structures, including multiple layers of nested objects, arrays and various basic data types, which makes the construction of debugging request messages extremely complex and tedious.

[0003] In particular, in enterprise-level applications, a single API interface may contain dozens or even hundreds of parameters, and there are complex hierarchical relationships and dependencies between these parameters. For example, a user registration API may need to include multiple nested objects such as user basic information, address information, contact information, etc., and each object contains several sub-fields. When developers need to debug such an API, manually constructing a JSON request message is not only time-consuming and laborious, but also prone to errors. Incorrect request format can cause debugging failure, affecting development efficiency and prolonging project delivery cycle.

[0004] Traditional API debugging methods mainly rely on manual operation and experience accumulation of developers. Developers usually need to perform the following steps: first, carefully read the API documentation to understand the meaning, type and hierarchical relationship of each parameter; second, manually write a JSON-formatted request message according to the documentation description; finally, use Postman, curl or other debugging tools to send requests and observe the response results.

[0005] For the above traditional API debugging method, since the complex API documentation often contains a large number of parameter descriptions, developers need to spend a lot of time to understand the hierarchical relationships and constraints between parameters, and the JSON format has strict syntax requirements, missing or misplacing parentheses, quotes, commas will cause format errors. For deeply nested structures, developers are prone to confusion in hierarchical relationships, resulting in incorrect placement of parameters.

[0006] In summary, in the face of complex API interfaces with numerous parameters and deeply nested structures, the error rate of traditional API debugging methods is significantly increased, which seriously affects development efficiency and debugging quality. Therefore, there is an urgent need for an automated solution to simplify the API debugging process, reduce human errors and improve development efficiency. SUMMARY

[0007] The embodiment of the present application provides a method and device for automatically generating a debugging request message based on API metadata, which can effectively reduce manual errors and improve development efficiency.

[0008] To achieve the above object, the embodiment of the present application adopts the following technical scheme:

[0009] In a first aspect, a method for automatically generating a debugging request message based on API metadata is provided, which is applied to a server, and the method comprises the following steps:

[0010] In response to receiving an API debugging request of a client, an API identifier is obtained, and API parameter metadata is obtained from a target database according to the API identifier, wherein the API parameter metadata comprises a parameter identifier, a parameter code, a parameter type and hierarchical relationship information;

[0011] The API parameter metadata is converted from a flat structure into a tree structure with hierarchical relationship, and a parent-child relationship between parameters is determined by analyzing the parameter identifier, and parameters with the same parent identifier are classified into corresponding hierarchical nodes;

[0012] Based on the tree structure, a recursive algorithm is used to construct a debugging request message;

[0013] According to the parameter type, a nested mapping structure is created for an object type parameter in the debugging request message, a list structure is created for an array type parameter in the debugging request message, and a preset debugging default value is filled for a basic type parameter in the debugging request message, so as to obtain a debugging request message after parameter adjustment;

[0014] The debugging request message after parameter adjustment is converted into a JSON format and returned to the client.

[0015] In a possible implementation manner of the first aspect, the API parameter metadata obtained from the target database according to the API identifier comprises the following steps:

[0016] A service property corresponding to the API identifier is determined;

[0017] In the case that the service property is a private service, a private API parameter query interface is called to obtain a first query result from the target database;

[0018] In the case that the service property is a public service, a public API parameter query interface is called to obtain a second query result from the target database;

[0019] Filter metadata records with the parameter type of input parameter from the first query result and the second query result as API parameter metadata.

[0020] In a possible implementation form of the first aspect, the converting the API parameter metadata from a flat structure into a tree structure with a hierarchical relationship comprises:

[0021] Traverse each parameter record in the API parameter metadata list, and extract the parameter identifier and the parameter code of each parameter record;

[0022] Calculate the parent identifier by removing the parameter code at the end from the parameter identifier;

[0023] Group the parameter records according to the parent identifier, and classify the parameter records with the same parent identifier into the same hierarchical node;

[0024] Build a mapping structure with the parent identifier as the key and the parameter record list as the value, to form the tree structure.

[0025] In a possible implementation form of the first aspect, the constructing a debugging request message based on the tree structure comprises:

[0026] Start from the root node of the tree structure, and obtain the parameter list of the current level;

[0027] Traverse each parameter of the current level, and execute corresponding processing logic according to the data type of the parameter;

[0028] Add the processed object or list with the parameter code as the key to the message mapping of the current level, to obtain the debugging request message;

[0029] The processing logic comprises:

[0030] In the case that the data type of the parameter is an object type, create a new mapping object, and take the parameter code of the current parameter as the prefix of the child node, and recursively call itself to process the child level parameters;

[0031] In the case that the data type of the parameter is an array type, create a list object, and take the parameter code of the current parameter as the prefix of the child node, and recursively call itself to process the array element parameters, and add the processing result to the list object.

[0032] In a possible implementation form of the first aspect, the constructing a debugging request message based on the tree structure comprises:

[0033] Start from the root node of the tree structure, and obtain the parameter list of the current level;

[0034] traversing each parameter of the current level, performing corresponding processing logic according to a data type of the parameter;

[0035] adding the processed object or list with the parameter code as a key into a message mapping of the current level to obtain a debugging request message;

[0036] The processing logic comprises:

[0037] in a case where the data type of the parameter is an object type, creating a new mapping object, taking the parameter code of the current parameter as a sub-node prefix, and recursively calling the self to process the parameter of the sub-level;

[0038] in a case where the data type of the parameter is an array type, creating a list object, taking the parameter code of the current parameter as a sub-node prefix, recursively calling the self to process the parameter of the array element, and adding the processing result into the list object.

[0039] In a possible implementation of the first aspect, the processing logic comprises:

[0040] in a case where the data type of the parameter is a numerical value type, matching a preset paging parameter rule according to a parameter identifier;

[0041] in a case where the parameter identifier is a current page identifier, taking a numerical value 1 as a parameter value;

[0042] in a case where the parameter identifier is a target page identifier, taking a numerical value 1 as a parameter value;

[0043] in a case where the parameter identifier is a line number per page identifier, taking a numerical value 20 as a parameter value;

[0044] in a case where the data type of the parameter is another numerical value type, filling a numerical value 0 as a default value.

[0045] In a possible implementation of the first aspect, before the message is constructed based on the tree structure by using the recursive algorithm, the method further comprises:

[0046] determining whether the tree structure has a missing necessary parameter node;

[0047] in a case where the tree structure does not have the missing necessary parameter node, verifying a dependency relationship between parameters to ensure that a parent parameter exists and a corresponding child parameter structure is complete;

[0048] in a case where the verification fails, generating an error prompt information and terminating the message construction process.

[0049] In a possible implementation manner of the first aspect, the converting the debugging request message with the adjusted parameters into a JSON format and returning to the client comprises:

[0050] using a JSON serialization tool to convert a mapping structure of the debugging request message with the adjusted parameters into a JSON string;

[0051] creating an API debugging information object and setting the JSON string as a request body content;

[0052] constructing a response object containing a success status code and a success message, and encapsulating the API debugging information object into the response object;

[0053] returning the response object to the client.

[0054] In a second aspect, the present application provides a server, comprising:

[0055] a memory configured to store instructions; and

[0056] a processor configured to invoke the instructions from the memory and capable of implementing the above-mentioned API metadata-based automatic generation method of a debugging request message when executing the instructions.

[0057] In a third aspect, the present application provides a machine readable storage medium, which stores instructions for causing a machine to execute the above-mentioned API metadata-based automatic generation method of a debugging request message.

[0058] By the technical solution, the parameter management mechanism based on the metadata realizes the standardization and centralized management of API parameter definition, avoids the problems of scattered and inconsistent parameter information, and provides a reliable data foundation for automatic message generation. Secondly, the intelligent conversion algorithm from the flat structure to the tree structure can automatically identify the hierarchical relationship between parameters, and can process the nested parameter structure of any complexity without manual intervention, greatly reducing the technical threshold of message construction. Thirdly, the application of the recursive algorithm enables the message construction process to be adaptive to different API structure complexities, whether it is a simple single-layer parameter or a deeply nested multi-layer object, it can be accurately converted into the correct message format. In addition, the intelligent default value filling mechanism automatically fills in appropriate test data according to the parameter type and semantic characteristics, and the generated debugging request message has high usability, and the developer can directly use it for API testing without a large amount of manual modification. Finally, the standardized JSON output format ensures that the generated message can be correctly parsed and used by various debugging tools and clients. Overall, this method shortens the manual message construction work of tens of minutes or even hours to seconds, significantly improves the API debugging efficiency, reduces human errors, and speeds up the software development cycle.

[0059] Other features and advantages of the embodiments of the present application will be described in detail in the subsequent specific embodiments part. BRIEF DESCRIPTION OF DRAWINGS

[0060] Figure 1 A flowchart of a debugging request message automatic generation method based on API metadata provided by the embodiments of the present application is shown.

[0061] Figure 2 An interaction schematic diagram between the client, the server and the target database provided by the embodiments of the present application is shown. DETAILED DESCRIPTION

[0062] In order to make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. It should be understood that the specific embodiments described herein are only used to illustrate and explain the embodiments of the present application, and are not used to limit the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0063] It should be noted that if the embodiments of the present application involve directional indications (such as up, down, left, right, front, back, etc.), the directional indications are only used to explain the relative position relationship, movement condition, etc. between components in a certain posture (as shown in the drawings), if the certain posture changes, the directional indications also change accordingly.

[0064] In addition, if the description of "first", "second" and the like is involved in the embodiments of the present application, the description of "first", "second" and the like is only for the purpose of description, and cannot be understood as indicating or implying the relative importance of the technical features indicated or implicitly indicating the number of technical features. Therefore, the features limited by "first", "second" can explicitly or implicitly include at least one of the features. In addition, the technical solutions of various embodiments can be combined with each other, but it must be based on the realization of ordinary skilled in the art, when the combination of technical solutions appears contradictory or unachievable, it should be considered that the combination of technical solutions does not exist, nor in the protection scope required by the present application.

[0065] Figure 1 The flowchart of the method for automatically generating a debugging request message based on API metadata according to an embodiment of the present application is schematically shown. As shown in Figure 1 The method for automatically generating a debugging request message based on API metadata according to an embodiment of the present application is provided, which is applied to a server. The method can include the following steps.

[0066] S110, in response to receiving the API debugging request of the client, obtaining the API identification, and querying the API parameter metadata from the target database according to the API identification, the API parameter metadata including parameter identification, parameter code, parameter type and hierarchical relationship information;

[0067] S120, converting the API parameter metadata from a flat structure to a tree structure with hierarchical relationship, determining the parent-child relationship between parameters by analyzing the parameter identification, and classifying parameters with the same parent identification into the corresponding hierarchical nodes;

[0068] S130, based on the tree structure, using a recursive algorithm to construct a debugging request message;

[0069] S140, according to the parameter type, creating a nested mapping structure for the object type parameter in the debugging request message, creating a list structure for the array type parameter in the debugging request message, and filling the debugging default value of the preset for the basic type parameter in the debugging request message, to obtain the debugging request message after parameter adjustment;

[0070] S150, converting the debugging request message after parameter adjustment into JSON format and returning to the client.

[0071] Referring to Figure 2When the server receives an API debugging request from the client, it first extracts the API identification information from the request. The API identification usually exists in the form of a string, which can be a unique number of the API, an interface path, or a predefined identifier. After receiving the API identification, the server immediately starts the database query process, retrieves all parameter metadata information related to the API identification from the pre-configured target database by constructing a SQL query statement or calling a database access interface.

[0072] The target database stores a complete API parameter definition table, and each record contains key fields such as parameter identification, parameter code, parameter type, and hierarchical relationship information. The parameter identification uses a dot-separated hierarchical structure to represent the complete path of the parameter in the entire API structure; the parameter code is a simplified name of the parameter in the current level; the parameter type defines the data type of the parameter, including basic types such as string, integer, object, and array; and the hierarchical relationship information maintains the tree structure relationship between parameters through the parent identification field. In the actual query process, the server performs a query operation based on the API identification and returns all parameter definition records of the API interface. The query results are encapsulated into a list of parameter metadata objects, each object containing complete parameter description information, providing a data basis for subsequent tree structure construction and message generation. This parameter management method based on metadata ensures the consistency and maintainability of parameter definitions, avoiding the maintenance difficulties caused by hard-coded parameter structures.

[0073] API parameter metadata is usually stored in a database as flat records, each representing an independent parameter definition, lacking intuitive hierarchical relationship representation. To construct an effective request message, these flat parameter records need to be reorganized into a tree structure with explicit parent-child relationship. The conversion process first traverses all parameter metadata records obtained from database query, and parses the parameter identifier for each record. The parameter identifier adopts a dot format, such as "user.profile.address.street", and by analyzing the dot separator in the identifier, the hierarchical position of the parameter in the entire API structure can be determined. The specific parent-child relationship determination algorithm is: for any parameter identifier, by removing the last dot and the parameter code part after it, the parent identifier can be obtained. For example, the parent identifier of "user.profile.address.street" is "user.profile.address". Based on this parent identifier calculation rule, the algorithm creates a mapping structure with the parent identifier as the key and the child parameter list as the value. In the traversal process, parameters with the same parent identifier are automatically classified into the same hierarchical node, forming a clear tree hierarchy. For root-level parameters (i.e. parameter identifiers without dots), their parent identifier is an empty string, and they will be classified into the root node of the tree structure. This conversion mechanism can handle nested structures of any depth, whether it is a simple two-level nesting or a complex multi-level nested object, and can be correctly organized into a tree structure, providing a clear data organization form for subsequent recursive message construction.

[0074] Based on the constructed tree structure, a recursive algorithm is used to generate the debug request message. The recursive algorithm starts from the root node of the tree structure, first obtains the list of all root-level parameters, and then processes each parameter one by one. For each parameter, the algorithm will execute different processing logic branches according to its parameter type.

[0075] When encountering an object type parameter, the algorithm creates a new mapping object (Map or Dictionary structure), and then uses the parameter code of the current parameter as a child node lookup prefix to locate all child parameters of the parameter in the tree structure, and recursively calls itself to process these child parameters, filling the results of recursive processing into the newly created mapping object.

[0076] For array type parameters, the algorithm creates a list object (List or Array structure) and looks up the parameter definition of the array elements with the current parameter's parameter code as prefix, recursively processes the structure of array elements, and adds the processing result to the list object. The termination condition of the recursive call is that there is no child parameter in the current level, at which point the algorithm returns the constructed object or list structure. The entire recursive process uses a depth-first traversal strategy to ensure that each nested level is completely processed. The advantage of the recursive algorithm is that it can automatically adapt to any complexity of nested structure, regardless of the number of levels in the API parameter structure, the algorithm can build the complete message structure layer by layer through recursive calls. After processing is complete, all objects and lists are added to the message map of the current level with the corresponding parameter code as the key, and finally the complete debug request message skeleton structure is formed.

[0077] After the recursive algorithm constructs the basic message structure, it needs to make fine adjustments and data filling to the message content according to different parameter types. For object type parameters, the algorithm creates a nested map structure (such as HashMap or Dictionary), which can accommodate all attribute fields of the object. Each attribute is stored in the form of key-value pair, with the key being the attribute name and the value being the actual data or nested object of the attribute.

[0078] For array type parameters, the algorithm creates a list structure (such as ArrayList or List), which can contain multiple elements, each of which can be a basic data type, an object, or a nested array. To facilitate debugging, the algorithm usually pre-fills an example element in the array, which contains the complete structure definition of the array element type. For basic type parameters, the algorithm fills in the corresponding preset debugging default value according to the specific data type of the parameter. String type parameters will be filled with example texts such as "test" or "sample"; integer type parameters will be filled with numerical values such as 0 or 1; boolean type parameters will be filled with true or false; date and time type parameters will be filled with the current time or a fixed example time format.

[0079] In particular, for some parameters with special semantics, the algorithm applies intelligent recognition rules. For example, when the parameter name contains keywords such as "page", "pageNum", etc., it is identified as a pagination parameter and filled with 1; when the parameter name contains keywords such as "size", "pageSize", etc., it is filled with reasonable pagination size values such as 10 or 20; when the parameter name contains the "id" suffix, it is filled with an example ID value. This intelligent default value filling mechanism greatly improves the practicality and testability of the generated debug request message, and developers can directly use the generated message for API debugging without manually modifying a large number of parameter values.

[0080] The debug request message after parameter adjustment needs to be converted to standard JSON format to be correctly recognized and processed by the client and API interface. The JSON conversion process uses professional serialization tools or library functions to execute, ensuring that the generated JSON string conforms to the standard format specification. The serialization process traverses the entire message mapping structure, converting each key-value pair to a JSON attribute format. Object types are converted to JSON objects (enclosed in curly braces), array types are converted to JSON arrays (enclosed in square brackets), string types are enclosed in double quotes, numeric types remain in their original format, and boolean types are converted to true or false literals. During the serialization process, the algorithm automatically handles the escape of special characters such as double quotes, backslashes, and line breaks, ensuring that the generated JSON string is syntactically correct. After conversion, an API debug information object is created, which contains multiple fields: the request body content field stores the generated JSON string, the API identification field stores the original API identification information, the generation time field records the timestamp of the message generation, and the parameter statistics field records the total number of parameters and other meta-information. Next, a standard HTTP response object is constructed, setting the success status code (such as 200) and the success message (such as "message generation successful"). The API debug information object is encapsulated into the data field of the response object. Finally, the complete response object is returned to the client through the HTTP protocol. After receiving the response, the client can directly extract the JSON format debug request message for subsequent API interface debugging work. This standardized response format ensures that the client can uniformly process the debug request generation results of various APIs, improving the automation level and user experience of the entire debugging process.

[0081] The embodiment effectively solves the complexity and error-prone problems of manual construction of request messages in the traditional API debugging process. The parameter management mechanism based on metadata realizes the standardization and centralized management of API parameter definition, avoids the problem of scattered and inconsistent parameter information, and provides a reliable data foundation for automatic message generation. Secondly, the intelligent conversion algorithm from flat structure to tree structure can automatically identify the hierarchical relationship between parameters, and can process any complexity of nested parameter structure without manual intervention, greatly reducing the technical threshold of message construction. Thirdly, the application of recursive algorithm makes the message construction process adaptive to different API structure complexity, whether it is a simple single-layer parameter or a deeply nested multi-layer object, it can be accurately converted to the correct message format. In addition, the intelligent default value filling mechanism automatically fills in appropriate test data according to the parameter type and semantic characteristics, and the generated debugging request message has high usability, which can be directly used for API testing without a large amount of manual modification. Finally, the standardized JSON output format ensures that the generated message can be correctly parsed and used by various debugging tools and clients. Overall, this method shortens the manual message construction work of tens of minutes or even hours to seconds, significantly improves the API debugging efficiency, reduces human errors, and speeds up the software development cycle.

[0082] In one embodiment of the present embodiment, the API parameter metadata is obtained by querying the target database according to the API identifier, including the following steps:

[0083] S210, determine the service property corresponding to the API identifier;

[0084] S220, in the case of private service, calling a private API parameter query interface to obtain a first query result from the target database;

[0085] S230, in the case of public service, calling a public API parameter query interface to obtain a second query result from the target database;

[0086] S240, filtering the metadata records with input parameter type from the first query result and the second query result as API parameter metadata.

[0087] After receiving the API identifier, the service property corresponding to the API identifier needs to be determined first. The determination of service property is based on the pre-established service classification rules and identifier parsing algorithm. The API identifier usually contains characteristic information that can reflect its service property, such as the prefix of the identifier, the namespace or the specific marker field.

[0088] Private services usually have specific naming conventions, such as identifiers starting with "private.", "internal.", or enterprise-specific prefixes, which are only called by internal systems with stricter access control and permission verification mechanisms. Public services, on the other hand, use standardized naming conventions, such as identifiers starting with "public.", "api.v1.", or generic formats without special prefixes, which are open to external developers or partners.

[0089] The determination process employs a multi-level recognition strategy: first, it matches the format pattern of the API identifier through regular expressions to check if it contains the characteristic markers of private services; second, it queries the service registry or configuration database to verify the registered type of the API identifier in the service directory; finally, it combines the version information and access level attributes of the API identifier for comprehensive judgment. This precise service property recognition mechanism ensures that subsequent query operations can access the correct data sources and apply appropriate security policies, avoiding permission confusion and data leakage risks, while providing differentiated processing flows for different types of services.

[0090] When the API identifier is determined to be a private service property, a special private API parameter query interface needs to be called to obtain the corresponding parameter metadata. The private API parameter query interface has stricter security verification mechanisms and access control strategies to ensure that only authorized internal systems can access sensitive private service parameter information.

[0091] The calling process of the query interface first performs identity authentication to verify the legitimacy and permission level of the caller, usually using security mechanisms such as API keys, digital certificates, or OAuth tokens. After authentication, the interface constructs a query statement for the private service data table based on the API identifier. The parameter metadata of private services is usually stored in a database partition with higher security level or a special data table.

[0092] The query operation retrieves all parameter definition records related to the API identifier, including the complete identifier path, data type, validation rules, default value range, and access permissions. The parameter metadata of private services often contains more rich business logic information and constraint conditions, such as parameter dependency relationships, business rule verification, data desensitization requirements, etc. The query result is encapsulated into a structured first query result object, which not only contains basic parameter metadata, but also contains private service-specific security markers, audit information, and permission control fields.

[0093] For API identifiers recognized as public service nature, the public API parameter query interface needs to be called to obtain the corresponding parameter metadata information. The public API parameter query interface adopts a relatively loose access control strategy, but still maintains necessary security protection measures such as frequency limitation, IP whitelist verification, and basic identity authentication.

[0094] The parameter metadata of public services is usually stored in a special public database or data table, which has been standardized and security reviewed to ensure that no sensitive internal business information is included. After receiving the API identifier, the query interface will construct a standardized query statement to retrieve the matching record from the public service parameter table. The parameter metadata structure of public services is relatively simple, mainly including the basic attribute information of the parameter such as parameter identifier, parameter code, data type, whether it is required, parameter description, and other core fields, as well as the hierarchical relationship information required for constructing the request message.

[0095] Data filtering rules are applied in the query process to ensure that the returned parameter information meets the open standards and security requirements of public APIs, and sensitive fields that may leak internal implementation details are removed. The query result is organized into a second query result object, which adopts a standardized data format to facilitate subsequent processing and cross-platform compatibility. The public API parameter query interface also records query logs and usage statistics for API usage analysis and performance optimization.

[0096] Filter the metadata records of the input parameter type from the first query result and the second query result. API parameters are usually divided into multiple types, including input parameters (used to receive data transmitted from the client), output parameters (used to return response data to the client), and internal parameters. Since the purpose of debugging the request message is to construct the request data sent to the API interface, only the metadata records of the input parameter type need to be concerned.

[0097] The filtering process uses multiple filtering conditions to ensure the accuracy of the results: first, check the parameter type field in the parameter record, which usually uses enumeration values or standard codes to identify the purpose of the parameter; second, verify the direction attribute of the parameter to ensure that the parameter is transmitted from the client to the server; finally, check the visibility and validity markers of the parameter to exclude abandoned or internally used parameters.

[0098] The filtering algorithm will iterate through each parameter record in the query result, apply the filtering conditions one by one, and add the records that meet the input parameter characteristics to the final API parameter metadata set. During the filtering process, data integrity verification is also performed to ensure that each input parameter record contains the necessary fields required for constructing the request message, such as parameter identifier, parameter code, data type, etc. For records missing key fields, data completion or marking as abnormal records will be performed.

[0099] After the screening is completed, the obtained API parameter metadata set contains all valid input parameter definitions of the API interface, which will be used in subsequent tree structure construction and request message generation processes, effectively ensuring that the generated debugging request message only contains necessary input parameters, avoiding irrelevant parameter interference, and improving the accuracy and usability of the message.

[0100] The API parameter metadata query mechanism based on service property differentiation is used in the embodiment to realize differentiated processing of different types of services and accurate parameter information acquisition. The intelligent service property identification mechanism can automatically determine the service type according to the characteristics of the API identifier, avoiding the tediousness and errors of manual classification and ensuring the correct selection of subsequent query strategies. The separate query strategies for private services and public services ensure the security of sensitive internal service information and provide a convenient access way for public services, achieving a balance between security and ease of use. Special query interfaces and data sources are used for different service properties to ensure the accuracy and integrity of the parameter metadata, private services obtain more detailed business logic information, and public services obtain standardized open interface information. The accurate input parameter screening mechanism effectively filters irrelevant output parameters and internal parameters, ensuring that the generated debugging request message only contains necessary input parameters, avoiding parameter redundancy and confusion. Not only does it improve the accuracy and security of parameter metadata acquisition, but also provides personalized processing solutions for different types of API services, significantly improving the reliability and applicability of the entire debugging request message automatic generation process.

[0101] In one of the embodiments of the present embodiment, the API parameter metadata is converted from a flat structure to a tree structure with hierarchical relationships, including the following steps:

[0102] S310, traverse each parameter record in the API parameter metadata list, and extract the parameter identifier and parameter code of each parameter record;

[0103] S320, calculate the parent identifier by removing the parameter code at the end from the parameter identifier;

[0104] S330, group the parameter records according to the parent identifier, and classify the parameter records with the same parent identifier into the same hierarchical node;

[0105] S340, construct a mapping structure with the parent identifier as the key and the parameter record list as the value, forming a tree structure.

[0106] After obtaining the API parameter metadata, a systematic traversal and information extraction operation is required on the entire parameter metadata list. The traversal process uses an iterator pattern or loop structure to ensure that each parameter record in the list is processed completely. For each parameter record, the extraction operation focuses mainly on the parameter identifier and parameter code.

[0107] The parameter identifier is the complete path representation of the parameter in the entire API structure, using a dot-separated hierarchical format, which is used to express the hierarchical position and dependency of the parameter. The parameter code is a simplified name of the parameter in the current level, which represents the identifier of the parameter under its immediate parent node.

[0108] The extraction process needs to handle various exceptional cases, such as missing fields in parameter records, irregular formats, or containing special characters. For the parameter identifier field, format verification is performed to ensure that it conforms to the dot-separated hierarchical naming specification. For identifiers that do not conform to the specification, standardized processing rules are applied for format correction. The extraction of the parameter code is usually achieved through string splitting operations, i.e., extracting the string after the last dot in the parameter identifier as the parameter code.

[0109] During the extraction process, a mapping relationship between parameter records and their identifier information is established, providing data basis for subsequent grouping and tree structure construction, ensuring that the key identifier information of each parameter is accurately obtained and saved, laying a solid data foundation for complex hierarchical relationship analysis.

[0110] The calculation of the parent identifier determines the parent-child relationship of each parameter in the tree structure through precise string processing operations. The calculation process uses string cutting and analysis techniques, and the specific implementation is to remove the parameter code part at the end of the complete parameter identifier.

[0111] The algorithm first locates the position of the last dot in the parameter identifier, which is the key delimiter separating the parent path and the current parameter code. For example, for the parameter identifier "user.profile.contact.email", the algorithm locates the position of the last dot (between "contact" and "email"), then cuts all characters from the beginning of the string to the position before the dot, obtaining the parent identifier "user.profile.contact".

[0112] For root-level parameters (i.e., without a dot in the parameter identifier), such as "userId", their parent identifier is set to an empty string or a special root identifier. The algorithm also needs to handle edge cases such as an empty parameter identifier, only containing a dot, or starting / ending with a dot. String validation rules are applied during processing to ensure that the calculated parent identifier meets the expected format requirements. The calculated parent identifier is associated with the original parameter record, forming a mapping relationship between parameter records and parent identifiers.

[0113] Based on the calculated parent identifiers, a systematic grouping operation is needed for all parameter records, categorizing parameter records with the same parent identifier into the same level node. The grouping process uses a hash map or dictionary structure to organize data, with the parent identifier as the key value standard for grouping.

[0114] The algorithm iterates through all processed parameter records, checks the corresponding parent identifier for each record, and then adds the record to the corresponding group. If a parent identifier appears for the first time, the algorithm creates a new parameter list to store all parameter records under this group; if the parent identifier already exists, the current parameter record is added to the existing parameter list.

[0115] This grouping mechanism can automatically handle any complexity of hierarchical structure, and data consistency verification is performed during the grouping process to ensure that parameter records within the same group indeed belong to the same level, and to check for circular dependencies or unreasonable hierarchical relationships. For special cases such as root-level parameters (empty parent identifier), they are categorized into the root node group.

[0116] After grouping is complete, each hierarchical node contains all direct child parameters under this level, forming a clear hierarchical organization structure. This provides an ordered data organization form for the construction of tree structures, ensuring that subsequent recursive processing can follow the correct hierarchical relationship.

[0117] After completing parameter grouping, a standardized mapping structure needs to be constructed to represent the complete tree structure, with the parent identifier as the key and the corresponding parameter record list as the value. The mapping structure is constructed using efficient data structures such as HashMap, TreeMap, or Dictionary, ensuring fast key-value lookup and data access performance.

[0118] The construction process iterates through all grouping results, adding each parent identifier and its corresponding parameter record list to the mapping structure. The key of the mapping structure is a string type parent identifier, and the value is a list structure containing multiple parameter record objects. This design allows quick access to all child parameters under this level through the parent identifier, supporting efficient tree traversal and lookup operations.

[0119] In the construction process, the mapping structure is also optimized, such as sorting each parameter list in alphabetical order according to the parameter code, to ensure that the generated tree structure has consistent order. At the same time, a reverse index is established, that is, from any parameter record, the location and path in the tree structure can be quickly located. The mapping structure also contains metadata information, such as the depth of the tree, the total number of nodes, the number of leaf nodes, and other statistical information, to facilitate subsequent processing and optimization.

[0120] The constructed tree structure has good scalability and maintainability, supporting dynamic addition, deletion and modification of nodes.

[0121] The present embodiment realizes the intelligent reorganization of API parameter metadata and the establishment of hierarchical relationship through the flat structure to tree structure conversion mechanism. Comprehensive parameter information extraction ensures that the key identification information of each parameter record is accurately obtained, providing a complete data basis for subsequent hierarchical analysis. The accurate parent identification calculation algorithm accurately determines the parent-child relationship between parameters through string processing technology, so that no matter how complex the parameter structure is, it can be correctly parsed. The intelligent parameter grouping mechanism automatically classifies parameters with the same hierarchical attributes into corresponding nodes, forming a clear and orderly hierarchical organization structure. The standardized mapping structure construction provides an efficient data representation method for complex nested relationships. The entire conversion process has good fault tolerance and scalability, and can handle various abnormal situations and special formats to ensure the reliability of the conversion result. The flat parameter data that is difficult to handle is converted into an intuitive and clear tree structure, providing an ideal data organization form for subsequent recursive message construction, significantly improving the processing efficiency and accuracy of complex API parameter structures, and laying a solid technical foundation for the entire debugging request message automatic generation process.

[0122] In another embodiment, in order to reduce the error rate, the conversion of API parameter metadata from flat structure to tree structure with hierarchical relationship can also include the following steps:

[0123] S1, a multi-dimensional feature vector is constructed for each parameter, including a semantic embedding vector generated based on the parameter name and parameter description, a structure feature vector calculated based on the parameter structure feature, a business feature vector extracted based on the parameter business attribute, and a context feature vector constructed based on the parameter context relationship;

[0124] S2, a multi-dimensional similarity between parameters is calculated based on the multi-dimensional feature vector, and the multi-dimensional similarity is obtained by weighting and fusing the semantic similarity, the structure similarity, the business similarity and the context similarity;

[0125] S3, constructing a weighted directed graph according to the multi-dimensional similarity, wherein the nodes of the graph represent the parameters, and the edge weights of the graph represent the parent-child relationship probability between the parameters;

[0126] S4, analyzing the weighted directed graph by using a graph theory algorithm, processing the circular dependency through strong connected component detection, and determining the parent-child identification relationship between the parameters based on topological sorting and optimal path search;

[0127] S5, converting the API parameter metadata into a tree structure with a hierarchical relationship according to the determined parent-child identification relationship.

[0128] In the embodiment, a multi-dimensional feature vector is constructed for each parameter, including: encoding the parameter name and the parameter description by using a pre-trained lightweight semantic model to generate a 128-dimensional semantic embedding vector; calculating the structural features of the parameter, including the hierarchical depth of the parameter name, the parameter type complexity, the naming pattern score, and the point segmentation quantity, to form a 16-dimensional structural feature vector; extracting the business features of the parameter, including the system parameter identification, the pagination parameter identification, and the business domain attribution score, to form an 8-dimensional business feature vector; and constructing a 32-dimensional context feature vector based on the positional relationship of the parameter in the parameter list, the number of parameters at the same level, and the distribution of adjacent parameter types.

[0129] The multi-dimensional similarity between the parameters is calculated based on the multi-dimensional feature vector, including: calculating the semantic embedding vector similarity between the parameters by using the cosine similarity algorithm to obtain the semantic similarity; calculating the structural feature vector similarity between the parameters by using the reciprocal of the Euclidean distance to obtain the structural similarity; calculating the business feature vector similarity between the parameters based on the Hamming distance to obtain the business similarity; calculating the context feature vector similarity between the parameters by using the Pearson correlation coefficient to obtain the context similarity; and performing weighted summation on the semantic similarity, the structural similarity, the business similarity, and the context similarity according to preset weights to obtain the multi-dimensional similarity, wherein the weight of the semantic similarity is 0.4, the weight of the structural similarity is 0.3, the weight of the business similarity is 0.2, and the weight of the context similarity is 0.1.

[0130] The weighted directed graph is constructed according to the multi-dimensional similarity, including: selecting parameter pairs with a multi-dimensional similarity greater than a preset confidence threshold as candidate parent-child relationships; for each candidate parent-child relationship, calculating the parent-child relationship probability based on multiple heuristic rules, including the parameter name inclusion relationship, the parameter type compatibility, the business logic consistency, the parameter hierarchical depth rationality, and the historical success rate; regarding candidate relationships with a parent-child relationship probability greater than 0.7 as edges of the directed graph, and setting the edge weight as the corresponding parent-child relationship probability; and constructing a weighted directed graph with parameters as nodes and parent-child relationship probabilities as edge weights.

[0131] The weighted directed graph is analyzed by using a graph algorithm, including: using a strongly connected component algorithm to detect a strongly connected component in the weighted directed graph, to identify a parameter group with a circular dependency; for a strongly connected component containing multiple nodes, an optimal root node is selected based on a comprehensive score of in-degree, out-degree and edge weight of the node, and a hierarchical relationship within the component is constructed; for a single-node strongly connected component, the best parent node is determined by analyzing the edge weight of the predecessor node; an improved topological sorting algorithm is used to divide the entire directed graph into levels, to ensure the rationality and consistency of the parent-child relationship; the confidence threshold is adaptively adjusted based on the historical success rate, the threshold is lowered when the success rate is higher than 95%, and the threshold is increased when the success rate is lower than 85%.

[0132] The API parameter metadata is converted into a tree structure with a hierarchical relationship according to the determined parent-child identification relationship, including: based on the determined parent-child identification relationship, the parameters are grouped and sorted according to the hierarchical depth; a mapping structure is constructed with the parent-child identification as the key and the child parameter list as the value; the integrity and consistency of the tree structure are verified, to detect whether there are isolated nodes or unreasonable hierarchical relationships; when structural abnormalities are detected, an abnormality handling mechanism is started, to repair through alternative parent-child relationships or default hierarchical rules.

[0133] The embodiment realizes all-around feature description of the parameter relationship by constructing a feature vector containing four dimensions of semantics, structure, business and context. The 128-dimensional semantic embedding vector can deeply understand the semantic meaning of the parameter name and description, effectively identify the association relationship between synonyms, near synonyms and related concepts; the 16-dimensional structure feature vector accurately quantifies the hierarchical depth, type complexity and other structural properties of the parameter, providing an objective mathematical basis for hierarchical relationship judgment; the 8-dimensional business feature vector and the 32-dimensional context feature vector supplement key information from the perspectives of business logic and location relationship. Compared with the traditional single rule matching method, this multi-dimensional feature fusion mechanism can greatly improve the accuracy of parameter hierarchical relationship identification.

[0134] The introduction of the directed graph and the graph algorithm enables the system to handle complex scenarios that are difficult for traditional methods to solve. The strongly connected component detection algorithm can automatically identify and handle circular dependency problems, avoiding infinite recursion and logical conflicts; the topological sorting algorithm ensures the global consistency of the hierarchical relationship, eliminating the problem of unreasonable overall structure caused by local optimization; the optimal path search algorithm can select the optimal solution from multiple possible parent-child relationships, significantly improving the processing accuracy of complex nested structures. The scheme can handle deep nested structures of more than 10 layers and large API interfaces containing hundreds of parameters.

[0135] The parent-child relationship probability evaluation mechanism combining multi-dimensional similarity calculation and heuristic rules can automatically learn and adapt to different API design patterns and naming conventions without manually configuring complex rule sets; the adaptive threshold adjustment mechanism dynamically optimizes the confidence threshold according to the historical success rate, realizing continuous improvement of system performance; the exception handling and repair mechanism can automatically handle structural exceptions, greatly reducing system maintenance costs.

[0136] The parameter relationship identification can also find the implicit relationships that are easily missed by manual analysis, providing valuable suggestions for API document improvement and interface design optimization.

[0137] In one of the implementation manners of the embodiment, a recursive algorithm is used to construct the debugging request message based on the tree structure, including the following steps:

[0138] S410, starting from the root node of the tree structure, obtaining the parameter list of the current level;

[0139] S420, traversing each parameter of the current level, and executing corresponding processing logic according to the data type of the parameter;

[0140] S430, adding the processed object or list with the parameter code as the key to the message mapping of the current level to obtain the debugging request message;

[0141] The processing logic includes:

[0142] S440, in the case where the data type of the parameter is an object type, creating a new mapping object, and taking the parameter code of the current parameter as the prefix of the child node, recursively calling itself to process the parameters of the child level;

[0143] S450, in the case where the data type of the parameter is an array type, creating a list object, and taking the parameter code of the current parameter as the prefix of the child node, recursively calling itself to process the array element parameters, and adding the processing result to the list object.

[0144] The starting phase of the recursive algorithm starts from the root node of the tree structure. The root node usually corresponds to an empty string or a special root identifier in the tree structure, and contains the top-level parameter definition of the API interface. The operation of obtaining the parameter list of the current level is implemented by accessing the mapping structure, and the algorithm uses the identifier of the current level as the key value to retrieve the corresponding parameter record list from the mapping table of the tree structure.

[0145] In the initial call, the algorithm looks for all parameter records with an empty string as the parent identifier. These records include the root-level parameters of the API interface, such as user ID, request type, timestamp, and other top-level fields. The retrieval process involves: first, checking if the current level identifier exists in the mapping structure; second, verifying that the obtained parameter list is not empty or contains valid parameter records; and finally, sorting the parameter list to ensure that parameters are processed in the predefined order, usually in alphabetical order or importance priority based on parameter code.

[0146] The retrieval operation also records the current recursion depth and processing path for debugging and exception handling. If there are no parameter records in the current level, the algorithm returns an empty list and prepares to end the recursive call for the current branch. This ensures that the recursive algorithm starts from the correct starting point and processes all parameters in the expected hierarchical order, providing a reliable data source for subsequent type judgment and processing logic.

[0147] After obtaining the parameter list of the current level, each parameter needs to be processed individually based on its data type. The traversal process uses the iterator pattern to ensure that each parameter record in the list is processed completely. For each parameter, the algorithm first extracts its data type information, which is usually stored in the type field of the parameter record. Possible values include "object" (object type), "array" (array type), "string" (string type), "integer" (integer type), "boolean" (Boolean type), and other basic data types.

[0148] Type judgment uses a multi-conditional branching structure to execute specialized processing logic based on different data types. The selection of processing logic is based on type matching rules to ensure that each data type is correctly processed.

[0149] During type judgment, data validity verification is performed to check if the type information in the parameter record is complete and legal. For data types that cannot be identified, the algorithm applies a default processing strategy or records exception information.

[0150] After completing the type processing of a single parameter, the processing result needs to be added to the current level's message mapping structure in a standardized format. The message mapping uses a key-value pair data structure, with the key being the parameter code of the parameter and the value being the data object or list after type processing. The addition operation first verifies the validity of the processing result to ensure that the generated object or list meets the expected data format and structure requirements.

[0151] For object type processing results, the object is checked for necessary attribute fields and correct nested structure; for array type processing results, the array element type consistency and data integrity are verified; for basic type processing results, the value range, string format, and other constraint conditions are checked. The addition process adopts a safe data operation method to avoid key value conflicts and data coverage problems.

[0152] If the same parameter code is found to exist in the message mapping, the algorithm will handle it according to the predefined conflict resolution strategy, which may include overwriting the original value, merging data content, or reporting error information. The construction process of the message mapping also includes data format standardization to ensure that all added data meet the requirements of JSON serialization, such as correct handling of special characters, numerical precision, date format, etc. After completing all parameter addition operations, the message mapping of the current level contains the complete data representation of all parameters at this level.

[0153] When the data type of a parameter is identified as an object type, a corresponding nested mapping structure needs to be created to represent the internal attributes and hierarchical relationships of the object. The processing process first creates a new mapping object that will be used to store all child attributes of the current object parameter.

[0154] Next, the child node prefix is constructed by combining the parameter code of the current parameter with the dot separator to form a prefix identifier used to find the child level parameters. For example, if the parameter code of the current object parameter is "user", the child node prefix is "user.", which is used to locate all child parameters starting with "user." in the tree structure.

[0155] Based on the constructed child node prefix, the algorithm recursively calls itself to process all child level parameters of the object. The recursive call passes the child node prefix as a new level identifier, and the algorithm finds the corresponding child parameter list in the tree structure and repeats the type judgment and processing logic for each child parameter. The result of recursive processing is added to the newly created mapping object to form a complete object structure representation.

[0156] This recursive processing mechanism can automatically adapt to any depth of object nesting, whether the object contains how many levels of child objects, it can be correctly parsed and constructed. The processing process also includes loop dependency detection to prevent mutual reference between objects causing infinite recursion. The processing result of the object type is a complete mapping structure containing all child attributes, accurately reflecting the object hierarchical relationship in the original API parameter definition.

[0157] The handling of array type parameters requires the creation of a list structure to hold the array elements and recursive calls to handle the complex structure of the array elements. The array type handling logic first creates a new list object that will be used to store all the elements of the array.

[0158] Similar to object type handling, the algorithm constructs a subnode prefix to locate the parameter definition for the array element, typically in the format of the current parameter code plus an array index identifier. The parameter definition for the array element can be stored in the tree structure with a special identifier, and the algorithm will search the tree structure for the parameter definitions related to the array element, which describe the structure and properties that each element in the array should have.

[0159] For the found array element parameter definition, the algorithm recursively calls itself to handle, generating the data structure representing the array element. The result of the recursive handling can be a basic data type, an object structure, or a nested array, depending on the specific type definition of the array element. The processed array element is added to the list object, typically with one or more example elements to demonstrate the expected structure of the array.

[0160] For complex array structures, such as object arrays or multi-dimensional arrays, the algorithm is able to correctly handle various nesting scenarios through the recursive mechanism. The array type handling also takes into account the constraints of the array, such as minimum length, maximum length, element type restrictions, etc., to ensure that the generated array structure meets the requirements of the API interface. The final generated list object contains the complete structure representation of the array, providing the appropriate array data format for the debug request.

[0161] This embodiment realizes the automatic message generation of complex API parameter structures and accurate hierarchical relationship processing. Systematic parameter acquisition from the root node ensures that the recursive algorithm can process all parameters in the correct hierarchical order, providing a reliable starting point and data source for the entire construction process. The intelligent processing logic based on data types can automatically identify and handle various parameter types, whether simple basic types or complex nested structures can be properly processed.

[0162] The standardized message mapping construction mechanism ensures that the processing results can be correctly organized and stored to form a complete request message structure. The recursive processing capability of object types enables the algorithm to process nested objects of any depth, automatically construct complex object hierarchy relationships, and greatly simplify the processing difficulty of complex API structures. The specialized processing logic for array types provides complete support for various array structures, including basic type arrays, object arrays, and multi-dimensional arrays, and other complex cases. Overall, this recursive construction mechanism converts complex API parameter structures into standardized message formats, realizes the automatic conversion from abstract parameter definitions to specific request data, significantly improves the efficiency and accuracy of API debugging, and provides developers with powerful automated debugging tool support.

[0163] In one implementation of the embodiment, the corresponding processing logic is performed according to the data type of the parameter, including the following steps:

[0164] S510, in the case where the data type of the parameter is a string type, matching a preset system parameter rule according to the parameter identifier;

[0165] S520, in the case where the parameter identifier is an API method identifier, taking the API code as the parameter value;

[0166] S530, in the case where the parameter identifier is a version number identifier, taking the version number information as the parameter value, and filling in the version selection prompt information if the version number is empty;

[0167] S540, in the case where the parameter identifier is a character encoding identifier, taking the preset UTF-8 encoding as the parameter value;

[0168] S550, in the case where the parameter identifier is an encryption type identifier, taking the preset MD5 encryption type as the parameter value;

[0169] S560, in the case where the parameter identifier is a system tracking code identifier or a timestamp identifier, taking the current system timestamp as the parameter value;

[0170] S570, in the case where the data type of the parameter is other string types, filling in an empty string as the default value.

[0171] When the data type of the parameter is identified as a string type, an intelligent parameter identifier matching mechanism is needed to determine the specific use of the parameter and the default value to be filled in. String type parameters include system configuration parameters, business identifiers, encoding formats, encryption types, and other key information, so accurate rule matching is needed to ensure that each parameter can obtain appropriate default values.

[0172] The preset system parameter rule adopts a multi-level matching strategy. First, the naming features of the parameter identifier are matched through regular expression pattern matching. For example, parameters containing keywords such as "method", "version", "encoding", "encrypt", "trace", and "timestamp" are identified as specific system parameter types.

[0173] The rule matching engine also includes a fuzzy matching algorithm that infers the possible use of the parameter based on string similarity and semantic analysis when exact matching fails. During the matching process, a mapping relationship between the parameter identifier and the system parameter type is established, and each system parameter type corresponds to a specific default value generation strategy.

[0174] When the parameter identifier is matched as an API method identifier, the corresponding API code needs to be filled in as the default value of the parameter. API method identifiers usually use naming formats such as "method", "apiMethod", "methodName", and "action" to specify the specific API interface method that the client wants to call. The API code is obtained based on the API identifier information currently being processed, and the corresponding method code can be extracted by parsing the API identifier.

[0175] The generation process of the API code includes various conversion strategies: point format to camel case, underscore separation conversion, version number processing, etc. The conversion process also applies standardization rules to ensure that the generated API code meets the naming conventions and format requirements of the target system.

[0176] The filling of API code also considers the version compatibility of the interface. For the same interface of different versions, different method codes need to be filled. The filling process includes a verification mechanism to ensure that the generated API code is valid and identifiable. This method code automatic filling mechanism based on API identifier ensures that the debugging request can correctly specify the target interface method, avoids errors that may occur when manually filling in the method name, and improves the accuracy and usability of the debugging request.

[0177] The processing of version number identifier parameters needs to fill in the corresponding version number data according to the API version information to ensure that the debugging request can correctly specify the version of the target interface. Version number identifiers usually use naming formats such as "version", "apiVersion", "ver", and "v" to play a role in routing and compatibility control in API calls.

[0178] The version number information is obtained by extracting the version part from the current API identifier. The version information in the API identifier is usually in the format of "v1", "v2.0", "1.2.3", etc. The extraction process uses regular expression matching to identify various common version number formats, including the main version number, the secondary version number, the revision version number, and other complete semantic version identifiers.

[0179] When the API identifier contains explicit version information, the version number is directly filled as the parameter value. For cases where the version number is empty or the version information cannot be extracted from the API identifier, a version selection prompt is filled to guide the developer to manually specify the correct version number.

[0180] The character encoding identifier parameter processing involves setting the correct character encoding format for API debugging requests to ensure character correctness and compatibility during data transmission. The character encoding identifier usually uses the naming formats "encoding", "charset", "characterSet", "encode", etc. to specify the character encoding method of the request and response data.

[0181] UTF-8 encoding as the default preset value can correctly handle various language characters, including Chinese, English, special symbols, and other character sets. Since most API interfaces support UTF-8 encoding format, using this encoding can maximize the avoidance of character encoding mismatch problems.

[0182] The filling process will use the standard UTF-8 encoding identifier as the parameter value, and select the appropriate format according to the encoding specification of the target API. UTF-8 encoding can ensure the correct transmission of special characters and multi-byte characters.

[0183] The encryption type identifier parameter processing is used to specify the encryption algorithm type used for data encryption or signature verification in API debugging requests.

[0184] MD5 encryption type as the preset default value is based on its wide application and compatibility in API interfaces.

[0185] The system tracking code identifier and timestamp identifier parameter processing involves generating a unique tracking identifier and accurate time information for API debugging requests. The system tracking code identifier usually uses the naming formats "traceId", "requestId", "trackingCode", "correlationId", etc. to track the complete call link of a single request in a distributed system.

[0186] The timestamp identifier adopts the naming formats such as "timestamp", "time", "requestTime", "createTime", etc., and is used to record the initiation time of the request or the creation time of the data. The current system timestamp is obtained by using a high-precision time acquisition function, and is usually in the format of Unix timestamp with millisecond unit. This format has good cross-platform compatibility and accurate time representation capability.

[0187] For the system tracking code parameter, a unique identifier is generated based on the current timestamp.

[0188] For other string type parameters that cannot be matched to specific system parameter rules, an empty string is used as the default value filling strategy. Such parameters usually include business-related string fields such as user name, description information, note content, custom label, etc. The specific values of these parameters are highly dependent on the business scenario and test requirements, and cannot be intelligently filled by general rules.

[0189] The filling strategy of the empty string is based on the following considerations: first, the empty string is a safe default value that will not cause data type errors or format exceptions; second, the empty string can explicitly prompt the developer that the parameter needs to be manually filled with specific test data; finally, the empty string has good compatibility in the JSON serialization process.

[0190] The embodiment realizes the accurate identification of different purpose string parameters and the automatic filling of appropriate default values through the string type parameter processing mechanism based on intelligent matching of parameter identifiers. The preset system parameter rule matching mechanism can accurately identify various system level parameters, avoiding the tedious process of manually judging the purpose of the parameters, and greatly improving the automation degree of parameter processing.

[0191] The special processing strategy for API methods, version numbers, character encodings, encryption types, and other key system parameters ensures that these important parameters can obtain correct and effective default values, significantly improving the usability of generated debugging requests. The tracking code and timestamp generation mechanism based on the current system time provides unique identification information for each debugging request, facilitating subsequent debugging analysis and problem tracking.

[0192] In one of the embodiments of the present embodiment, the corresponding processing logic is executed according to the data type of the parameter, and further includes the following steps:

[0193] S610, in the case where the data type of the parameter is a numerical type, a preset paging parameter rule is matched according to the parameter identifier;

[0194] S620, in the case where the parameter identifier is the current page identifier, the numerical value 1 is taken as the parameter value;

[0195] S630. When the parameter identifier is the target page number identifier, the value 1 is used as the parameter value.

[0196] S640. When the parameter identifier is the number of rows per page, the value 20 is used as the parameter value.

[0197] S650. If the data type of the parameter is other numeric types, fill in the value 0 as the default value.

[0198] When a parameter's data type is identified as numeric, an intelligent parameter identifier matching mechanism is needed to determine whether the parameter belongs to a pagination-related system parameter. Numeric type parameters include important information such as pagination control, quantity limits, index positions, and service counts.

[0199] The preset pagination parameter rules employ a multi-layered identification strategy, determining pagination attributes by analyzing the naming characteristics of parameter identifiers. The pagination parameter identification rules include various naming patterns: the current page number parameter typically uses naming formats such as "page", "pageNum", "pageNumber", "currentPage", and "pageIndex"; the target page number parameter uses identifiers such as "targetPage", "toPage", and "gotoPage"; and the number of rows per page parameter uses naming conventions such as "pageSize", "size", "limit", "pageLimit", "perPage", and "rows".

[0200] The recognition process employs a combination of regular expression matching and keyword retrieval, capable of handling various naming styles, including camelCase, underscore-separated, and all-uppercase variations. During recognition, a mapping relationship can be established between parameter identifiers and pagination parameter types, with each pagination parameter type corresponding to a specific default value strategy.

[0201] The rule matching engine also includes fuzzy matching functionality. When an exact match fails, it can infer the possible uses of parameters based on string similarity and semantic analysis, ensuring that various pagination-related numerical parameters can be accurately classified and processed.

[0202] When a parameter identifier matches the current page number identifier, the value 1 is used as the default value for that parameter. The current page number parameter plays a crucial role in specifying the starting page for pagination queries and is the most fundamental and important control parameter in the pagination mechanism. The choice of 1 as the default value is based on the general convention of pagination systems; most pagination implementations use 1 as the page number for the first page, a convention that aligns with users' intuitive understanding and operational habits.

[0203] The process of filling the value 1 includes data type verification to ensure that the parameter can accept integer type values, and type conversion for floating point type page number parameters to ensure data format correctness.

[0204] The filling of the page number parameter also includes reasonableness verification to ensure that the filled page number value is within the valid range, avoiding negative or excessively large values. For API interfaces that support page range limits, the appropriate default page number value is determined based on interface documentation or configuration information. The value 1 filling strategy allows the generated debug request to be directly used to obtain the first page of data.

[0205] The target page number identification parameter is also filled with the value 1 as the default value, which is usually used to specify the target page of the page jump or the termination page of the query. The target page number parameter plays an important role in some complex pagination scenarios, such as pagination range queries, batch data processing, and pagination navigation. The value 1 as the default value of the target page number is based on the same design philosophy as the current page number parameter, ensuring consistency and logical reasonableness between pagination parameters.

[0206] When both the current page number and the target page number are set to 1, it usually represents a single page query or an operation starting from the first page, which is the most basic and common pagination scenario. The filling process of the target page number parameter includes relevance verification with the current page number parameter to ensure that the target page number is not less than the current page number, avoiding logically contradictory parameter combinations.

[0207] For API interfaces that support pagination range queries, the target page number parameter and the current page number parameter together define the query page range, and the value 1 filling ensures the minimum valid query range. The filling process also considers the reasonableness of the business scenario.

[0208] The processing of the number of rows per page identification parameter uses the value 20 as the default filling value, which is based on a comprehensive consideration of user experience and system performance. The number of rows per page parameter controls the number of data records returned by a single pagination query and is a key parameter affecting pagination query performance and user experience.

[0209] The choice of the value 20 as the default value is based on the following considerations: first, 20 records have a moderate data volume, providing enough information display without causing excessively large data volume for a single query; second, the value 20 has good display effects in web applications and mobile applications, meeting the pagination display needs of most interface designs; finally, a query of 20 records usually does not significantly affect database performance, making it a relatively safe default value.

[0210] The filling process of the number of rows per page parameter includes value reasonableness verification to ensure that the filled value is within the range allowed by the API interface, avoiding excessively small or large extreme values.

[0211] For other numerical type parameters that cannot be matched to the pagination parameter rules, the numerical value 0 is used as a general default padding value. Such parameters cover various business numerical fields in API interfaces, such as counters, index positions, quantity limits, priorities, status codes, business IDs, and various numerical parameters.

[0212] The selection of the numerical value 0 as the default value is based on its special status and wide applicability in the numerical system: first, 0 is the neutral value of the numerical system and does not have unexpected effects on most numerical operations and comparison operations; second, 0 represents the initial state, null value or default state in many business scenarios, with clear semantic meaning; finally, 0 as the default value does not cause data type errors or format exceptions, with good compatibility.

[0213] The padding process will perform corresponding format processing according to the specific data type of the parameter, filling the integer 0 for integer type parameters, filling the floating point number 0.0 for floating point number type parameters, and filling the corresponding format 0 value for long integer type parameters. The padding process also includes numerical range verification. For parameters with explicit range limits, it is checked whether 0 is within the allowed range. If 0 is not within the valid range, the value closest to 0 within the range is selected as the default value.

[0214] The embodiment realizes accurate classification of different purpose numerical parameters and automatic padding of reasonable default values through the numerical type parameter intelligent processing mechanism based on parameter semantic recognition. The preset pagination parameter rule matching mechanism can accurately identify various pagination related numerical parameters and automatically provide complete parameter configuration for pagination query scenarios, greatly simplifying the debugging work of pagination API. The special processing strategy for key pagination parameters such as the current page number, target page number and number of rows per page ensures that the generated debugging request has reasonable pagination configuration, and developers can directly use these requests for pagination function testing. The default value selection based on business experience and performance considerations reflects the system's deep understanding of actual application scenarios, improving the practicality and operability of the debugging request. The strategy of using 0 as a general default value for non-pagination type numerical parameters ensures the correctness of the numerical type and avoids possible business logic conflicts. The entire numerical parameter processing mechanism has good scalability and adaptability, can handle various naming conventions and business scenarios, and is suitable for different types of API interfaces.

[0215] In one of the embodiments of the present embodiment, before constructing the debugging request message based on the tree structure using the recursive algorithm, the method further includes the following steps:

[0216] S710, determining whether the tree structure has a missing necessary parameter node;

[0217] S720, in the case where the tree structure does not have a missing necessary parameter node, verify the dependency relationship between parameters to ensure that the parent parameter exists when the corresponding child parameter structure is complete;

[0218] S730, in the case of verification failure, generate an error prompt message and terminate the message construction process.

[0219] Before starting the recursive construction of the debug request message, a comprehensive integrity check of the tree structure is needed to determine whether there are missing necessary parameter nodes. Necessary parameter nodes refer to those parameter definitions that are marked as required or are essential for the normal operation of the API interface. The absence of these parameters will cause the API call to fail or return an error response.

[0220] The checking process first needs to establish the identification criteria for necessary parameters, which are determined by analyzing the required field in the parameter metadata to determine which parameters belong to necessary parameters.

[0221] The checking algorithm uses a depth-first traversal strategy to check each level and node of the tree structure, verifying whether all necessary parameters have corresponding parameter definitions. During the traversal process, a comparison mapping between the list of necessary parameters and the actual existing parameters is established, and set operations are used to identify missing parameter items.

[0222] The checking process also includes parameter path integrity verification to ensure that the complete hierarchical path of necessary parameters exists in the tree structure, avoiding parameter access anomalies caused by the absence of intermediate levels.

[0223] After confirming that the tree structure does not have a missing necessary parameter node, the dependency relationship between parameters needs to be further verified to ensure the structural integrity and logical consistency between parent parameters and child parameters. The verification process uses a top-down hierarchical traversal strategy, starting from the root parameter and checking the relationship integrity of each parent parameter and its corresponding child parameter layer by layer. For each object type parent parameter, the verification algorithm checks whether it has a complete child parameter structure definition, including all necessary attribute fields and optional extension fields.

[0224] The verification process also checks the type consistency of child parameters to ensure that the data types of child parameters match the attribute definitions of parent objects. For array type parent parameters, the verification algorithm checks whether the type definition of array elements is complete, including element structure, constraint conditions and value range, etc.

[0225] Dependency relationship verification also includes circular dependency detection to prevent the formation of mutual reference circular structures between parameters, causing infinite recursion. During the verification process, a parameter dependency graph is established to detect and identify potential dependency problems through graph theory algorithms.

[0226] When abnormal conditions are found in the parameter integrity check or dependency verification process, detailed error prompt information is generated and the message construction process is terminated. The generation of error prompt information uses a structured error report format, including error type, error location, error description, and suggested solutions, among other multi-dimensional diagnostic information.

[0227] Error type classification includes missing essential parameters, dependency abnormalities, parameter type mismatches, and structural integrity issues, among other categories, each with corresponding error codes and standardized description templates. Error location information is precisely located to specific parameter paths and hierarchical nodes, using a dot-separated format to identify the exact location of the problem.

[0228] Error prompt information includes contextual information such as related API identifiers, processing timestamps, system versions, and other information to facilitate problem tracking and reproduction. The termination process uses a resource cleanup mechanism to ensure that allocated memory and system resources are properly released, avoiding resource leakage issues.

[0229] This embodiment realizes quality assurance and abnormal protection of the debug request message construction process. The integrity check of essential parameter nodes ensures that all key parameters exist in the tree structure, preventing API call failures due to parameter missing from the source, greatly improving the success rate of generating debug requests.

[0230] The depth verification of parameter dependency ensures the logical correctness and integrity of complex nested structures, avoiding message construction abnormalities caused by incomplete structures, and ensuring that the generated request message has the correct hierarchical relationship. The structured error prompt information generation mechanism provides developers with detailed and valuable problem diagnosis information, including error location, error type, and solution suggestions, greatly reducing the difficulty of problem positioning and repair.

[0231] In one embodiment of the present embodiment, the parameter-adjusted debug request message is converted to JSON format and returned to the client, including the following steps:

[0232] S810, using a JSON serialization tool to convert the mapping structure of the parameter-adjusted debug request message to a JSON string;

[0233] S820, creating an API debug information object and setting the JSON string as the request body content;

[0234] S830, constructing a response object containing a success status code and a success message, and encapsulating the API debug information object into the response object;

[0235] S840, returning the response object to the client.

[0236] The parameter-adjusted debug request message needs to be converted into a standard JSON string format through a JSON serialization tool to ensure that the generated data can be correctly parsed and processed by various clients and API interfaces. Common serialization tools include mature JSON processing libraries such as Jackson, Gson, FastJSON, etc. These tools all have complete conversion capabilities from Java objects to JSON strings.

[0237] The serialization process first traverses the complete mapping structure of the debug request message, which contains all parameter data after recursive algorithm construction and parameter type adjustment. The traversal process uses a depth-first strategy to ensure that nested objects and array structures are correctly processed.

[0238] For each key-value pair in the mapping structure, the serialization tool will perform the corresponding conversion operation according to the value's data type: string type will be added with double quotes and special character escape processing; numerical type remains the original format output, integer directly outputs the number, floating-point number maintains the decimal point format; boolean type is converted to true or false literal; object type is converted to JSON object format surrounded by curly braces; array type is converted to JSON array format surrounded by square brackets.

[0239] The serialization process also includes data integrity verification to ensure that no parameter information is lost or damaged during the conversion process. The generated JSON string is format-verified to ensure compliance with JSON standard specifications, avoiding parsing failures caused by syntax errors.

[0240] After the JSON string is generated, a special API debug information object needs to be created to encapsulate and organize all information related to debugging. The API debug information object is designed with a structured data model, containing multiple key fields to comprehensively describe various aspects of the debug request.

[0241] The request body content field is used to store the generated JSON string, which is the core content of the debug information object and contains complete API call parameter data. In addition to the request body content, the API debug information object also contains other important metadata fields: the API identification field records the API interface identification currently being processed, facilitating client identification and management; the API name field provides a readable name for the interface; the request method field specifies the HTTP request method; the request URL field contains the complete API call address; the request header field defines the necessary HTTP request header information.

[0242] The generation time field records the timestamp of the message generation; the parameter statistics field counts the total number of parameters; the structure depth field records the maximum nesting level of the parameters.

[0243] After the API debug information object is created, a standardized HTTP response object needs to be constructed to encapsulate the debug results and return them to the client. The construction of the response object follows the standard response format of RESTful APIs, ensuring that the client can uniformly handle various API call results.

[0244] The core components of the response object include status code, message content, and data payload. The success status code is usually set to 200 (HTTP OK), indicating that the request processing is successful and the result is returned normally. The status code is the standard code in the HTTP protocol that indicates a successful response. The success message field uses standardized description text.

[0245] The data payload part encapsulates the API debug information object as the main content, usually placed in the data or result field of the response object. The response object also contains other auxiliary fields: the timestamp field records the time when the response is generated; the request ID field provides a unique identifier for the request, facilitating log tracking and problem positioning; the server information field identifies the server instance that processed the request; and the version information field indicates the version number of the API service.

[0246] The construction process also adds response header information, such as Content-Type set to application / json, to ensure that the client can correctly parse the response content.

[0247] The constructed response object needs to be returned to the client through the HTTP protocol, completing the last link of the entire debug request message generation process. The return process uses the standard HTTP response mechanism to ensure that the data can be correctly received and processed by the client.

[0248] The return operation first performs the final serialization of the response object, converting the response object into a JSON-formatted string. This process is similar to the aforementioned JSON serialization, but it is targeted at the structure of the response object. After serialization, appropriate HTTP response headers are set.

[0249] After successful return, log the operation, including processing time, response size, client information, and other statistical data for performance monitoring and system optimization. After the client receives the response, it can directly extract the JSON-formatted debug request message for subsequent API interface debugging work.

[0250] The embodiment realizes the standardized output and reliable transmission of the debugging request message through the complete JSON format conversion and response return mechanism. The use of the professional JSON serialization tool ensures the accurate conversion of the complex mapping structure to the JSON string, and the generated JSON format strictly conforms to the standard specification, has good cross-platform compatibility and parsability. The structured API debugging information object design provides rich metadata information, including not only the core request body content, but also API identification, generation time, parameter statistics and other valuable auxiliary information, greatly improving the integrity and practicability of the debugging information. The standardized HTTP response object construction follows the best practices of RESTful API, including clear status code, descriptive message and structured data payload, ensuring that the client can uniformly process various response results.

[0251] The embodiment provides a standardized output interface for the entire debugging request message automatic generation system, ensures that the generated debugging request can be correctly received and used by various client tools, significantly improves the efficiency and convenience of API debugging work, and provides a complete automatic debugging solution for developers.

[0252] The embodiment of the present application also provides a server, comprising:

[0253] a memory configured to store instructions; and

[0254] a processor configured to call the instructions from the memory and capable of realizing the API metadata-based debugging request message automatic generation method described above when executing the instructions.

[0255] The embodiment of the present application also provides a machine-readable storage medium, which stores instructions for causing a machine to execute the API metadata-based debugging request message automatic generation method described above.

[0256] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system or a computer program product. Therefore, the present application can adopt a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware aspects. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer usable storage media containing computer usable program code (including but not limited to disk storage, CD-ROM, optical storage, etc.).

[0257] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flow or blocks Figure 1 one or more flow or blocks

[0258] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. Figure 1 one or more flow or blocks Figure 1 one or more flow or blocks

[0259] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flow or blocks Figure 1 one or more flow or blocks

[0260] In one typical configuration, the computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0261] The memory can include non-persistent memory and / or persistent memory, such as flash memory, read-only memory (ROM), and / or volatile or non-volatile random access memory (RAM), among others. The memory is an example of computer readable media.

[0262] Computer-readable media includes permanent and non-permanent, movable and non-movable media that can implement information storage by any method or technology. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device. According to the definition herein, computer-readable media does not include transitory media such as modulated data signals and carriers.

[0263] It should also be noted that the terms "comprising", "containing", or any other variant thereof are intended to cover non-exclusive inclusions, so that a process, method, article or apparatus that includes a list of elements does not only include those elements, but also includes other elements not explicitly listed, or further includes elements inherent in such a process, method, article or apparatus. Without more limitations, the element defined by the statement "comprising a" does not exclude the presence of additional identical elements in the process, method, article or apparatus that includes the element.

[0264] The above only is an embodiment of the present application, and is not used to limit the present application. For those skilled in the art, the present application can have various changes and variations. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present application shall be included in the scope of claims of the present application.

Claims

1. A method for automatically generating debug request messages based on API metadata, characterized in that, Applied to a server, the method includes: In response to receiving an API debugging request from a client, the API identifier is obtained, and API parameter metadata is retrieved from the target database based on the API identifier. The API parameter metadata includes parameter identifier, parameter code, parameter type, and hierarchical relationship information. The API parameter metadata is transformed from a flat structure into a tree structure with hierarchical relationships. The parent-child relationship between parameters is determined by parsing the parameter identifier, and parameters with the same parent identifier are classified into the corresponding hierarchical nodes. Based on the tree structure, a recursive algorithm is used to construct the debug request message; Based on the parameter type, a nested mapping structure is created for the object type parameter in the debug request message, a list structure is created for the array type parameter in the debug request message, and preset debug default values ​​are filled into the basic type parameter in the debug request message to obtain the debug request message with adjusted parameters. The debug request message with adjusted parameters is converted into JSON format and returned to the client.

2. The method according to claim 1, characterized in that, The step of retrieving API parameter metadata from the target database based on the API identifier includes: Determine the service nature corresponding to the API identifier; In the case where the service is a private service, the private API parameter query interface is invoked to obtain the first query result from the target database; When the service is a public service, the public API parameter query interface is invoked to obtain a second query result from the target database. Metadata records with parameter type "input parameter" are selected from the first query results and the second query results and used as API parameter metadata.

3. The method according to claim 1, characterized in that, The process of converting the API parameter metadata from a flat structure to a hierarchical tree structure includes: Iterate through each parameter record in the API parameter metadata list and extract the parameter identifier and parameter code for each parameter record; The parent identifier is calculated by removing the parameter code at the end from the parameter identifier; The parameter records are grouped according to the parent identifier, and the parameter records with the same parent identifier are classified into the same level node; Construct a mapping structure with the parent identifier as the key and the parameter record list as the value to form the tree structure.

4. The method according to claim 1, characterized in that, The process of constructing a debug request message based on the tree structure using a recursive algorithm includes: Starting from the root node of the tree structure, obtain the parameter list for the current level; Iterate through each parameter in the current level and execute the corresponding processing logic based on the data type of the parameter; Add the processed object or list to the message mapping of the current level using the parameter code as the key to obtain the debug request message; The processing logic includes: If the parameter's data type is an object, create a new mapping object and recursively call itself to process the child level parameters, using the current parameter's parameter code as the prefix of the child node. If the parameter's data type is an array, create a list object, and recursively call itself to process the array element parameters, using the parameter code of the current parameter as the prefix of the child nodes, and add the processing results to the list object.

5. The method according to claim 4, characterized in that, The step of executing corresponding processing logic based on the data type of the parameters includes: When the parameter's data type is string, the system matches the preset parameter rules based on the parameter identifier; If the parameter identifier is an API method identifier, the API code will be used as the parameter value; If the parameter identifier is a version number identifier, the version number information is used as the parameter value; if the version number is empty, the version selection prompt information is filled in. When the parameter identifier is a character encoding identifier, the preset UTF-8 encoding is used as the parameter value; When the parameter identifier is an encryption type identifier, the preset MD5 encryption type is used as the parameter value; If the parameter identifier is a system tracking code identifier or a timestamp identifier, the current system timestamp will be used as the parameter value. If the parameter's data type is another string type, fill it with an empty string as the default value.

6. The method according to claim 4, characterized in that, The step of executing the corresponding processing logic based on the data type of the parameter also includes: If the parameter's data type is numeric, match the preset pagination parameter rules based on the parameter identifier; If the parameter identifier is the current page number identifier, the value 1 will be used as the parameter value; If the parameter identifier is the target page number identifier, the value 1 will be used as the parameter value; When the parameter identifier is the number of rows per page, the value 20 is used as the parameter value; If the parameter's data type is other numeric types, fill in the value 0 as the default value.

7. The method according to claim 1, characterized in that, Before constructing the debug request message using a recursive algorithm based on the tree structure, the method further includes: Determine whether the tree structure contains any missing necessary parameter nodes; In the absence of any missing necessary parameter nodes in the tree structure, the dependencies between parameters are verified to ensure that the corresponding child parameter structure is complete when the parent parameter exists. If verification fails, an error message is generated and the message construction process is terminated.

8. The method according to claim 1, characterized in that, The step of converting the adjusted debug request message into JSON format and returning it to the client includes: Use a JSON serialization tool to convert the mapping structure of the debug request message with adjusted parameters into a JSON string; Create an API debugging information object and set the JSON string as the request body content; Construct a response object containing a success status code and a success message, and encapsulate the API debugging information object into the response object; The response object is returned to the client.

9. A server, characterized in that, include: The memory is configured to store instructions; as well as A processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the method for automatically generating debug request messages based on API metadata as described in any one of claims 1 to 8.

10. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores instructions for causing the machine to execute the method for automatically generating debug request messages based on API metadata as described in any one of claims 1 to 8.

Images