An interface information processing method, apparatus, device, and storage medium

Abstract

This disclosure relates to the field of computer technology, and in particular to an interface information processing method, apparatus, device, and storage medium to achieve efficient and accurate merging of APIs. The method includes: extracting APIs to be processed from business traffic logs; if the API to be processed matches any interface merging strategy, updating API statistics on the generalized API record corresponding to that interface merging strategy; if the match fails, storing it as an unmerged API in a database. At a preset trigger time, unmerged APIs are read from the database, the path segments of each API to be merged are determined, and path segments that conform to preset generalization rules are replaced with wildcards to generate candidate generalized APIs; if the number of original APIs corresponding to candidate generalized APIs is greater than a threshold, the corresponding original APIs are deleted, a new generalized API record corresponding to the candidate generalized API is added, and a corresponding interface merging strategy is generated and added to the interface merging strategy set.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to an interface information processing method, apparatus, device and storage medium. Background Technology

[0002] In a microservice architecture, the Application Programming Interface (API) is the core carrier for data interaction between systems. The API monitoring system analyzes business traffic to collect API data, enabling API asset management and security risk monitoring.

[0003] However, the API collection extracted from business traffic contains a large number of duplicate or similar APIs, such as similar page interfaces corresponding to different user IDs. These duplicate or similar APIs can lead to the following problems: an explosion in the API asset ledger, with the number of APIs far exceeding the actual number of interfaces; redundant database storage, increasing storage costs; duplicate calculation of statistical data such as API access counts; and low information retrieval efficiency due to duplicate matching consuming computing resources. Summary of the Invention

[0004] In view of this, the present disclosure provides an interface information processing method, apparatus, device and storage medium to achieve efficient and accurate merging of similar APIs, effectively reduce interface asset redundancy and improve API asset management efficiency.

[0005] Firstly, a method for processing interface information is provided, comprising: real-time parsing of business traffic logs to extract application programming interfaces (APIs) to be processed; matching the APIs to be processed with an acquired set of interface merging strategies; if the APIs to be processed match any interface merging strategy, updating API statistics on the generalized API record corresponding to any interface merging strategy; if the matching fails, storing the APIs to be processed as unmerged APIs in a database; at a preset trigger time, reading the unmerged APIs from the database to obtain a set of APIs to be merged; determining the path segments of each API to be merged in the set of APIs to be merged, matching the path segments with preset generalization rules, replacing path segments that conform to the preset generalization rules with wildcards to generate candidate generalized APIs; counting the number of original APIs corresponding to each candidate generalized API; if the number of original APIs is greater than a preset merging threshold, deleting the original APIs corresponding to the candidate generalized APIs from the database, adding a generalized API record corresponding to the candidate generalized APIs in the database, generating an interface merging strategy corresponding to the candidate generalized APIs, and adding it to the set of interface merging strategies.

[0006] In one implementation, determining the path segment of each API to be merged in the set of APIs to be merged includes: extracting the path portion of each API to be merged in the set of APIs to be merged, splitting the path portion according to a preset delimiter, and obtaining multiple path segments.

[0007] In one implementation, matching the path segment with preset generalization rules includes: matching the path segment with each default rule and custom rule in the preset generalization rules one by one; if the path segment conforms to any rule in the default rule or the custom rule, then the path segment is determined to be a replaceable path segment, and a wildcard is used to replace the replaceable path segment to generate the candidate generalized API.

[0008] In one implementation, the default rule includes at least one of the following: a pure numeric rule for identifying path segments composed of numeric characters; a hexadecimal string rule for identifying path segments composed of hexadecimal characters with a length conforming to a preset number of digits; a Universally Unique Identifier (UUID) format rule for identifying path segments conforming to the UUID format; and / or, the custom rule is configured by the user and represents the matching pattern of the path segments in the form of a combination of wildcards and fixed strings.

[0009] In one implementation, the step of counting the number of original APIs corresponding to each candidate generalized API includes: using the candidate generalized API as the key, querying whether the key corresponding to the candidate generalized API already exists in the aggregation container; if it does not exist, creating a new set of original APIs, adding the original APIs to the set, and storing the key corresponding to the candidate generalized API and the set of original APIs in the aggregation container as key-value pairs; if it already exists, adding the original APIs to the set of original APIs corresponding to the key in the aggregation container; after traversing all APIs to be merged in the set of APIs to be merged, obtaining the number of APIs in the set of original APIs corresponding to each candidate generalized API from the aggregation container, as the number of original APIs corresponding to each candidate generalized API.

[0010] In one implementation, after determining that the number of original APIs exceeds a preset merging threshold and before performing deletion and addition operations, the method further includes: using the request method, parameter name set, response data structure, and call context of each original API in the original API set corresponding to the candidate generalized API as input parameters, mapping the input parameters to semantic vectors using a pre-trained semantic model to obtain semantic vectors corresponding to each original API; calculating the semantic similarity and structural similarity between each original API in the original API set based on the semantic vectors and the path structure of the candidate generalized APIs, and weighting and fusing the semantic similarity and structural similarity to obtain a comprehensive similarity score; when the comprehensive similarity score exceeds a preset dynamic threshold, determining that the original API set corresponding to the candidate generalized API can perform the deletion and addition operations; the preset dynamic threshold is adaptively adjusted according to the business module to which the original APIs belong.

[0011] In one implementation, the method further includes: statistically analyzing the proportion of newly added APIs that cannot match any interface merging strategy within a preset time period to obtain a matching failure rate; when the matching failure rate exceeds a corresponding preset monitoring threshold, triggering an incremental learning task to analyze the set of APIs that have not been merged to obtain candidate generalization rules; applying the candidate generalization rules to the verification set traffic within a preset verification time period to verify the merging quality; if the verification determines that the candidate generalization rules meet the preset indicator requirements, then the candidate generalization rules are included in the interface merging strategy set.

[0012] Secondly, an interface information processing device is provided, comprising: The traffic parsing module is used to parse business traffic logs in real time and extract the application programming interface (API) to be processed. The interface merging strategy execution module is used to match the API to be processed with the acquired set of interface merging strategies. If the API to be processed matches any interface merging strategy, the API statistics information is updated on the generalized API record corresponding to any interface merging strategy. If the matching fails, the API to be processed is stored in the database as an unmerged API. The API merging module, at a preset trigger time, reads unmerged APIs from the database to obtain a set of APIs to be merged; determines the path segments of each API to be merged in the set, matches the path segments with preset generalization rules, replaces path segments that conform to the preset generalization rules with wildcards, and generates candidate generalized APIs; counts the number of original APIs corresponding to each candidate generalized API, and if the number of original APIs is greater than a preset merging threshold, deletes the original APIs corresponding to the candidate generalized APIs from the database, adds a new generalized API record corresponding to the candidate generalized APIs in the database, and generates an interface merging strategy corresponding to the candidate generalized APIs, which is then added to the interface merging strategy set.

[0013] Thirdly, an electronic device is provided, including a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and the processor is configured to execute the machine-readable instructions stored in the memory, wherein when the machine-readable instructions are executed by the processor, the processor performs the steps of any of the interface information processing methods described above.

[0014] Fourthly, a computer-readable storage medium is provided, including instructions stored thereon, wherein, when the instructions are executed by a processor, the interface information processing method as described in any of the above embodiments is executed.

[0015] This disclosure employs a combined online and offline approach. During the real-time parsing phase, the API to be processed is matched against the interface merging strategy set. If a match is successful, the statistical information on the generalized API record is directly updated, avoiding the statistical delays caused by a purely offline solution. Simultaneously, at a preset trigger time, unmatched APIs are processed offline in batches, providing double protection for the merging operation. This dual-protection merging mechanism prevents the same business interface from being split into multiple independent entries for separate counting due to different dynamic parameters in the URL, improving statistical accuracy. Furthermore, during the offline phase, by splitting the API path into segments, matching it with generalization rules, using wildcard replacement to generate candidate generalized APIs, and combining this with a quantity threshold to determine whether to perform merging, merging accuracy can be significantly improved. Moreover, after offline merging is completed, a new interface merging strategy is generated and added to the online application's merging strategy set, so that merged APIs do not need to be repeatedly entered into the database in subsequent accesses, reducing storage redundancy and computational resource consumption. This disclosure solution is simple and efficient, requiring no complex information entropy calculations, easy to implement and maintain, and can effectively reduce interface asset redundancy and improve API asset management efficiency. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating an exemplary embodiment of the present disclosure of an interface information processing method; Figure 2 This is a schematic diagram illustrating an API acquisition process according to an exemplary embodiment of this disclosure; Figure 3 This is an exemplary embodiment of the present disclosure illustrating the specific workflow of an API merging module; Figure 4 This is a schematic diagram of an interface information processing apparatus 400 shown in an exemplary embodiment of the present disclosure; Figure 5 This is a schematic diagram of an electronic device 500 illustrated in an exemplary embodiment of the present disclosure. Detailed Implementation

[0017] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0018] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0019] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0020] Furthermore, the symbol “ / ” in this disclosure indicates that there is an “or” relationship between the related objects before and after the symbol, or that the related objects have an exemplary relationship that can coexist.

[0021] Research has revealed that as enterprise business systems continue to expand, microservice architecture has become the mainstream technology choice, and APIs, as the core carriers of data interaction and function calls between systems, are experiencing exponential growth in number. API monitoring systems can continuously monitor and analyze business system traffic, monitor API interface risks, and efficiently and stably monitor the data security of API interfaces. Collecting APIs from business systems by analyzing access traffic can comprehensively uncover the interface assets of the target business system, thereby completely reconstructing the interface set of the business system. However, the API collection extracted from business traffic often contains a large number of duplicate and similar APIs. For example, the following example shows different access interfaces for multiple similar pages: Example 1: / pikachu / vul / xss / xss_01.php / pikachu / vul / xss / xss_02.php / pikachu / vul / xss / xss_04.php Example 2: / portal / pls / portal / DEV1_PORTAL_DEMO.ORG_CHART.SHOW / portal / pls / portal / DEV3_PORTAL_DEMO.ORG_CHART.SHOW / portal / pls / portal / DEV6_PORTAL_DEMO.ORG_CHART.SHOW The following example shows multiple accesses to the same interface: Example 3: / Nmap / folder / check1756160195 / Nmap / folder / check1756153795 / Nmap / folder / check1756180262 Example 4: / api / endpoints / 1 / docker / containers / 698d51a19d8a121ce581499d7b701668 / api / endpoints / 1 / docker / containers / bcbe3365e6ac95ea2c0343a2395834dd / api / endpoints / 1 / docker / containers / 310dcbbf4cce62f762a2aaa148d556bd Duplicate or similar APIs can lead to: an overabundance of API assets, with the number of APIs far exceeding the actual number of interfaces in the business system, making asset management difficult; redundant database storage, increasing storage costs and data maintenance complexity; inaccurate API data statistics (e.g., duplicate counting of access times); and low information retrieval efficiency (similar APIs require repeated matching, consuming computing resources).

[0022] Based on this, embodiments of this disclosure provide an interface information processing method. This method accurately identifies and effectively merges similar APIs, ensuring processing efficiency while effectively reducing the number of interface assets, lowering storage overhead, and improving statistical accuracy and retrieval efficiency. For example, using the method of embodiments of this disclosure, the aforementioned duplicate or similar APIs can be identified as pointing to the same generalized API, such as: The API in Example 1 can be generalized as: ; The API in Example 3 can be generalized as: .

[0023] The methods of the embodiments of this disclosure will now be described in detail with reference to the accompanying drawings. Please refer to... Figure 1 , Figure 1 This is a flowchart illustrating an interface information processing method provided in an embodiment of this disclosure. The method specifically includes the following steps S101 to S105. The executing entity for these steps can be an API monitoring system, an API collection device, or a network security device with corresponding functions. This embodiment uses an API collection device as an example for illustration. The interface information processing method includes: S101: Perform real-time analysis of business traffic logs and extract application programming interface (API) files to be processed.

[0024] Here, S101 and subsequent S102 refer to the online processing phase. Business traffic logs refer to Hypertext Transfer Protocol (HTTP) / Hypertext Transfer Protocol Secure (HTTPS) communication records generated by the business system during operation. These logs typically include information such as the request method, request Uniform Resource Locator (URL), request headers, request body, response status code, and response time. These logs can originate from traffic mirrors deployed in a bypass mode, gateway access logs, or proxy server logs. Pending APIs refer to a specific API call instance parsed from a single traffic log entry, typically represented as a complete request URL (including the path and possible query parameters).

[0025] In practical implementation, a traffic parsing module can receive business traffic logs in real time (e.g., through a distributed message queue system like Kafka, the System Logging Protocol (Syslog), or by directly reading log files), and perform protocol parsing on each log record. First, the request method (e.g., GET, POST) and URL are extracted from the HTTP request line. Second, the protocol, domain name, and port are extracted from the URL, retaining the path portion and query parameters (querystring). The extracted API information includes at least the request method and URL path; optionally, it may also include a set of query parameter keys and key fields in the request header (e.g., Content-Type). After parsing, the API to be processed is temporarily stored in a structured form (e.g., JavaScript Object Notation (JSON) or data table row records) for subsequent matching steps.

[0026] S102: Match the API to be processed with the obtained set of interface merging strategies. If the API to be processed matches any interface merging strategy, update the API statistics information on the generalized API record corresponding to any interface merging strategy. If the matching fails, store the API to be processed as an unmerged API in the database.

[0027] Here, the interface merging strategy refers to predefined or offline-generated matching rules used to determine whether a specific original API should belong to a certain generalized API. For example, the interface merging strategy may include type judgment based on path segments (e.g., "pure numeric" parts should be generalized), or it may include custom wildcard rules, such as... _PORTAL_DEMO.ORG_CHART.SHOW, APIs matching this pattern are all merged into the corresponding generalized API.

[0028] For example, the interface merging strategy can be indicated using regular expressions, such as ^ / Nmap / folder / check\d+$, which indicates that APIs matching this pattern are all merged into the generalized API / Nmap / folder / check. .

[0029] The generalized API record refers to an abstract API representation that removes the dynamically variable parts, used to represent a set of similar original APIs. For example, .

[0030] The API statistics package may include, but is not limited to, the source IP address of the access, the number of accesses, the distribution of request methods, the set of request parameter names, and the distribution of response status codes. This information is used for subsequent asset analysis and security monitoring.

[0031] This step involves sequentially or quickly matching the API to be processed extracted by S101 with the set of interface merging strategies currently loaded into memory (e.g., stored in a hash table or prefix tree Trie). The matching method can be regular expression matching, wildcard matching, or segment-by-segment matching based on path splitting. If a match is successful (e.g., matching strategy for the API to be processed GET / pikachu / vul / xss / xss_01.php), the matching strategy will be determined. If the strategy is not found, the corresponding generalized API record will be located directly, and the statistics therein will be updated (such as incrementing the access count by 1, merging the source IP set, etc.).

[0032] If a match fails, it indicates that the current API does not belong to any known generalized API category. It will be stored as an unmerged API in the database (such as a relational database or NoSQL database) and await subsequent offline merging processing.

[0033] S103: At a preset trigger time, read all unmerged APIs from the database to obtain a set of APIs to be merged.

[0034] This step marks the start of the offline processing phase. The preset trigger time can be dynamically updated based on traffic volume. For example, to avoid interference with real-time processing during peak periods, a fixed time during off-peak hours might be chosen to execute the offline batch merging task, such as 00:30:00 daily. This time can be configured based on the traffic characteristics of the business system, offering flexibility.

[0035] In practical implementation, a scheduled task (such as one based on Quartz or Linux crontab) can be used to automatically wake up the API merging module, which is responsible for API detection and merging during the offline phase, at a preset trigger time each day. The API merging module queries the database, filters out all original API records that have not yet been merged (e.g., identified by a boolean field is_merged=false), and reads them into memory all at once or in batches, forming a set of original APIs to be merged. Since step S103 is executed only at the preset trigger time, rather than in real time, the impact on online traffic processing performance can be reduced.

[0036] S104: Determine the path segment of each API to be merged in the set of APIs to be merged, match the path segment with the preset generalization rule, and replace the path segment that conforms to the preset generalization rule with a wildcard to generate candidate generalized APIs.

[0037] For example, path segmentation can be multiple fragments obtained by splitting the URL path of the API by forward slashes ( / ). For example, / pikachu / vul / xss / xss_01.php can be split into ["pikachu", "vul", "xss", "xss_01.php"].

[0038] The preset generalization rules are used to determine whether a path segment should be considered a "variable part" and generalize accordingly. For example, they may include: default rules such as "pure numbers (e.g., 123)," "hexadecimal strings," "UUID format," "timestamp format," etc. Custom rules may also be included: regular expressions or string patterns that users can configure based on business characteristics, such as... .

[0039] For each API to be merged obtained in step S103, the API merging module first extracts its URL path portion (ignoring query parameters), and then splits it by a delimiter such as " / ", resulting in a segment array. Each segment in this array is iterated over and matched against a preset set of generalization rules. If a segment matches any rule, for example, if the segment value is: 698d51a19d8a121ce581499d7b701668 matches the rule for "32-bit hexadecimal string"; Then replace the segment with a wildcard (e.g., After all segments are processed, the replaced segments are reassembled using / to form candidate generalized APIs. Note: Query parameters are not merged at this time, but can be used as optional semantic features for expanding the scheme.

[0040] In one implementation, determining the path segment of each API to be merged in the set of APIs to be merged includes: extracting the path portion of each API to be merged in the set of APIs to be merged, splitting the path portion according to a preset delimiter, and obtaining multiple path segments.

[0041] Here, when determining the path segments for each API in the API set to be merged, the path portion of each API is first extracted. The path portion refers to the content remaining in the API's URL after removing the protocol, domain name, port, and query parameters. For example, for the API / pikachu / vul / xss / xss_01.php, its path portion is / pikachu / vul / xss / xss_01.php. After extraction, the path portion is split according to a preset delimiter, which in practice is usually a forward slash ( / ). Through splitting, the original complete path string is decomposed into multiple independent path segments. For example, splitting / pikachu / vul / xss / xss_01.php by forward slashes yields ["pikachu", "vul", "xss","xss_01.php"]. The purpose of this splitting process is to refine the API path into smaller, independent units, which makes it easier to perform generalized rule matching on each segment separately and accurately identify which parts of the path belong to dynamically changing parameters (such as user ID, timestamp, random number, etc.) and which parts belong to fixed business path identifiers.

[0042] In one implementation, matching the path segment with preset generalization rules includes: matching the path segment with the default rule and the custom rule in the preset generalization rules one by one; if the path segment conforms to either the default rule or the custom rule, then the path segment is determined to be a replaceable path segment, and a wildcard is used to replace the replaceable path segment to generate the candidate generalized API.

[0043] For example, after splitting the path into multiple path segments, these segments need to be matched against preset generalization rules. Specifically, each path segment is matched one by one against the default rules and custom rules in the preset generalization rules. The default rules are built-in general rules that take effect without user configuration and are used to identify common dynamic data types; the custom rules are configured by the user according to the URL organization structure of the business system and are used to handle special dynamic patterns in specific business scenarios. During the matching process, if a path segment matches any rule in the default rules or custom rules, the segment is determined to be a replaceable path segment, and then a wildcard (usually 0) is used. The segment is replaced. After all segments have been processed, all segments (including fixed segments that were not replaced and dynamic segments that were replaced with wildcards) are reassembled according to the delimiter to generate candidate generalized APIs. For example, for API / Nmap / folder / check1756160195, if its last segment is determined to be a replaceable path segment, it is replaced and reassembled to obtain candidate generalized APIs. .

[0044] In one implementation, the default rules include at least one of the following: a pure numeric rule for identifying path segments composed of numeric characters; a hexadecimal string rule for identifying path segments composed of hexadecimal characters with a length conforming to a preset number of digits; a Universally Unique Identifier (UUID) format rule for identifying path segments conforming to the UUID format; the custom rules are configured by the user and represent the matching pattern of path segments in the form of a combination of wildcards and fixed strings.

[0045] The default rules and custom rules in the above embodiments have specific rule definitions. Default rules include at least one of the following: Pure numeric rules are used to identify path segments consisting entirely of numeric characters (0-9), such as 123, 1756160195, etc. In actual business systems, dynamic parameters of numeric types are quite common, such as user ID ( / user / 123 / profile), order number ( / order / 202304150001), timestamp ( / data / 1704067200), pagination page number ( / list / page / 2), and the random numeric suffix in example 3 above ( / Nmap / folder / check1756160195). Although these numeric segments have different values ​​each time, their common characteristic is that they are all composed of numeric characters (0-9). Without generalization, each different numeric value will generate an independent API entry, leading to an explosion of API asset ledger entries. The regular expression ^\d+$ is used to quickly determine whether a path segment consists entirely of numeric characters. If the determination is true, the segment is identified as dynamic content that should be generalized and replaced with wildcards, such as " ".

[0046] Hexadecimal string rules are used to identify dynamic content such as hash values ​​or identifiers generated by specific algorithms, such as MD5 values, SHA values, or UUIDs. Although these identifiers differ in value with each API access, their format is highly uniform: they consist entirely of hexadecimal characters (0-9, af, AF), and their length is fixed to a specific value (e.g., 32 bits for MD5, 40 bits for SHA-1, and 64 bits for SHA-256). Therefore, this rule satisfies two conditions: first, all characters in the path segment must be hexadecimal characters; second, the length of the segment must meet the preset bit length requirements (e.g., common hash lengths such as 16, 32, 40, and 64). Segments that only meet the character set constraints but do not match the length (e.g., only 4 characters "abc1" or 8 characters "deadbeef") will not be matched by this rule to avoid misidentifying hexadecimal strings with business meaning (such as username abbreviations, version numbers, or file identifiers) as dynamic content that should be generalized. By verifying both the character set and length, the identifiers generated by the algorithm can be locked, allowing for accurate replacement of such dynamic content with wildcards during the merging operation, thus generating the correct generalized API. Taking Example 4 above as an example, the segments such as "698d51a19d8a121ce581499d7b701668" simultaneously meet the conditions of being composed of hexadecimal characters and having a length of 32 bits. Therefore, they are identified by this rule as dynamic content to be generalized, and the resulting generalized API is: “ ".

[0047] The Universally Unique Identifier (UUID) format rules are used to identify path segments (dynamic identifiers) that conform to the UUID standard format. Its standard form is typically a 36-bit string (including hyphens) of 8-4-4-4-12 or a 32-bit hexadecimal string without hyphens. For example, a UUID is a 128-bit identifier that can be separated by hyphens according to the 8-4-4-4-12 rule (36 bits including hyphens, such as 550e8400-e29b-41d4-a716-446655440000), or a continuous 32-bit hexadecimal string without hyphens (such as 698d51a19d8a121ce581499d7b701668 in example 4). Although the value of a UUID changes randomly with each access, its format is highly standardized. The character set is limited to hexadecimal characters, and the length and hyphen position follow a fixed pattern. By matching standard formats using regular expressions, such identifiers can be accurately identified without being confused with other strings that are also composed of hexadecimal characters but have different lengths, thus achieving accurate generalization while avoiding false matches.

[0048] On the other hand, custom rules are flexibly configured by users according to business needs, and represent the matching pattern of path segments in the form of a combination of wildcards and fixed strings. When a path segment matches the matching pattern of the custom rule, the part of the path segment corresponding to the wildcard in the custom rule is replaced with a wildcard to generate a candidate generalized API.

[0049] For example, for example 2 above, the user can configure: ,in This is a wildcard that can match any string (such as DEV1, DEV3, DEV6, etc.). _PORTAL_DEMO.ORG_CHART.SHOW is a fixed suffix. This rule can accurately identify dynamic segments with business characteristics. By combining default and custom rules, it can cover common dynamic data types out of the box, and also supports users to flexibly extend it according to actual business scenarios, achieving accurate API generalization matching.

[0050] S105: Count the number of original APIs corresponding to each candidate generalized API. If the number of original APIs is greater than a preset merging threshold, delete the original APIs corresponding to the candidate generalized APIs from the database, add a new generalized API record corresponding to the candidate generalized API in the database, and generate an interface merging strategy corresponding to the candidate generalized API, which is then included in the interface merging strategy set.

[0051] Here, the preset merging threshold K is an integer parameter used to control the rigidity of the merging. APIs are only considered to be merged when the number of original APIs aggregated under a candidate generalized API exceeds this threshold. For example, when K=2, at least two different original APIs are required to trigger a merge. The threshold can be configured based on the total number of APIs in the business system and the desired merging granularity.

[0052] Through this step, the matching strategy (such as regular expression or wildcard pattern) corresponding to the newly generated generalized API can be dynamically added to the strategy set of the online traffic parsing module, so that subsequent APIs of the same type can be matched in real time and the statistics can be updated directly without having to be stored in the database to be merged again.

[0053] After all APIs to be merged are processed in step S104, a mapping relationship from candidate generalized APIs to the original API set is obtained (e.g., stored in an aggregation container such as a Map container, where map refers to a key-value pair collection data structure). This mapping is traversed, and the number of original APIs corresponding to each candidate generalized API is calculated. If this number is greater than a preset threshold K (e.g., K=2), the group of APIs is determined to be mergeable. The merging operation includes: physically or logically deleting (e.g., soft deletion) these original API records from the database; adding a new generalized API record in the database, the record content including the path of the generalized API, wildcard representation, creation time, and the number of associated original APIs; generating a corresponding interface merging strategy based on the generalized API (e.g., compiled into a regular expression or prefix tree node), and pushing this strategy to the interface merging strategy set of the online traffic parsing module for subsequent real-time matching. If the number of original APIs corresponding to a candidate generalized API is not greater than the merging threshold K, then merging is temporarily suspended, the original API records are retained, and further aggregation or manual review is pending.

[0054] In one implementation, the step of counting the number of original APIs corresponding to each candidate generalized API includes: using the candidate generalized API as the key, querying whether the key corresponding to the candidate generalized API already exists in the aggregation container; if it does not exist, creating a new set of original APIs, adding the original APIs to the set, and storing the key corresponding to the candidate generalized API and the set of original APIs in the aggregation container as key-value pairs; if it already exists, adding the original APIs to the set of original APIs corresponding to the key in the aggregation container; after traversing all APIs to be merged in the set of APIs to be merged, obtaining the number of APIs in the set of original APIs corresponding to each candidate generalized API from the aggregation container, as the number of original APIs corresponding to each candidate generalized API.

[0055] In this implementation, when counting the number of original APIs corresponding to each candidate generalized API, an aggregation container (usually a Map data structure, i.e., a collection of key-value pairs) is used to organize the data. Specifically, the candidate generalized API is used as the key, and the set of original APIs corresponding to that candidate generalized API is used as the value, and key-value pairs are constructed and stored in the aggregation container. After the candidate generalized API for an API to be merged is generated, the aggregation container is first queried to see if the key already exists. If the query result shows that the key does not exist in the aggregation container, it means that the current candidate generalized API is appearing for the first time. In this case, a new set of original APIs is created, the currently processed original API is added to the set, and then the candidate generalized API and the newly created set of original APIs are stored in the aggregation container as key-value pairs. If the query result shows that the key already exists in the aggregation container, it means that other original APIs have previously belonged to the same candidate generalized API. In this case, the currently processed original API is directly added to the existing set of original APIs corresponding to that key in the aggregation container, without creating a new set. The above operation is repeated for each API to be merged in the set of APIs to be merged until all APIs to be merged have been processed. After the traversal is complete, the number of APIs contained in the value (i.e., the original API set) corresponding to each key (i.e., each candidate generalized API) in the aggregation container is the number of original APIs corresponding to that candidate generalized API. The size of the original API set corresponding to each candidate generalized API is obtained by traversing each key-value pair in the aggregation container, and then compared with a preset merging threshold to determine whether the group of APIs should be merged.

[0056] In some embodiments, to further improve the accuracy of API merging and avoid erroneous merging of APIs with similar structures but different business meanings, a context-aware verification mechanism based on semantic similarity can be executed after determining that the number of original APIs exceeds the merging threshold and before performing database deletion and addition operations. Specific implementation methods are as follows.

[0057] Specifically, after determining that the number of original APIs exceeds a preset merging threshold and before performing deletion and addition operations, the process further includes: using the request method, parameter name set, response data structure, and call context of each original API in the original API set corresponding to the candidate generalized API as input parameters, mapping the input parameters to semantic vectors using a pre-trained semantic model to obtain the semantic vector corresponding to each original API; based on the semantic vectors and the path structure of the candidate generalized APIs, calculating the semantic similarity and structural similarity between each original API in the original API set, and weighting and fusing the semantic similarity and structural similarity to obtain a comprehensive similarity score; when the comprehensive similarity score exceeds a preset dynamic threshold (which can be queried from a preset business module threshold configuration table), determining that the original API set corresponding to the candidate generalized API can perform the deletion and addition operations; the preset dynamic threshold is adaptively adjusted according to the business module to which the original API belongs.

[0058] This implementation adds a semantic understanding-based verification step after the basic merging judgment condition (i.e., the number of original APIs corresponding to the candidate generalized API exceeds a preset merging threshold) is met and before the actual database deletion and addition operations are performed. First, multi-dimensional features of each original API in the original API set corresponding to the candidate generalized API are extracted as input parameters. These features include, but are not limited to, the API's request method (e.g., GET, POST, PUT, DELETE), parameter name set (i.e., parameter keys, not specific parameter values), response data structure (e.g., returned field names and nested structures), and calling context (e.g., other APIs that typically appear before or after this API in the call sequence). Then, a pre-trained semantic model (e.g., an embedded representation model for code or APIs, such as CodeBERT, or a dedicated model trained for the API context) is used to map these input parameters into high-dimensional semantic vectors, thus obtaining the semantic vector representation corresponding to each original API. Based on this, the semantic similarity (obtained by calculating the cosine distance of the semantic vectors) and structural similarity (using the path splitting and rule matching methods in the basic scheme) between each original API in the original API set are calculated. Next, the calculated semantic similarity and structural similarity are weighted and fused, that is, they are combined into a comprehensive similarity score according to a preset weight allocation (e.g., semantic similarity weight is 0.6, structural similarity weight is 0.4). If the comprehensive similarity score exceeds a preset dynamic threshold, the original API set corresponding to the candidate generalized API is determined to be ready for subsequent deletion and addition operations (i.e., formal merging). This dynamic threshold is not a fixed value, but is adaptively adjusted according to the business module to which the original API belongs. The threshold for the corresponding module can be queried from a preset business module threshold configuration table. For example, the threshold for the user management module can be set lower (because the API of this module has high uniformity), while the threshold for the transaction module is set higher (to avoid erroneously merging transaction operations with different semantics). The merging operation will only be finally executed when the comprehensive similarity score exceeds the dynamic threshold corresponding to the business module. Through the above mechanism, the judgment of API merging is elevated from traditional syntax pattern matching to the semantic understanding level, which can avoid the problem of erroneous merging caused by structural similarity but different business semantics, thereby further improving the business rationality of the merging result.

[0059] In some embodiments, to address the issue of new API types constantly emerging during the continuous evolution of business systems and the difficulty of real-time coverage by statically preset rules, and to enable the merging strategy to automatically evolve with business changes and reduce manual intervention costs, an adaptive learning mechanism based on matching failure rate monitoring can be introduced. Specific implementation methods include: The percentage of newly added APIs that cannot match any interface merging strategy within a preset time period is counted to obtain the matching failure rate. When the matching failure rate exceeds the corresponding preset monitoring threshold, an incremental learning task is triggered to analyze the set of APIs that have not been merged and obtain candidate generalization rules. The candidate generalization rules are applied to the verification set traffic within a preset verification time period to verify the merging quality. If the verification confirms that the candidate generalization rule meets the preset indicator requirements, the candidate generalization rule is included in the set of interface merging strategies.

[0060] This implementation adds a feedback-driven adaptive learning mechanism to the basic merging scheme, which can automatically discover newly emerging API patterns and generate corresponding merging strategies without waiting for manual configuration. Specifically, a statistical monitor is set up in the traffic parsing module to count in real time or periodically the proportion of new APIs that cannot match any existing interface merging strategy within a preset time period (e.g., the past 24 hours) to the total number of new APIs in that time period. This proportion is the matching failure rate. When the matching failure rate exceeds a preset monitoring threshold (e.g., the threshold is set to 10%, meaning that more than 10% of APIs cannot be covered by existing strategies), an incremental learning task is automatically triggered without waiting for the daily fixed offline merging cycle. After the incremental learning task is started, the set of APIs that have not been merged is automatically analyzed. Frequent pattern mining algorithms (such as the Apriori algorithm or FP-Growth algorithm) are used to identify frequently occurring replaceable patterns from the path segments of these APIs. These patterns include frequently occurring 8-digit pure numeric strings, 32-bit hexadecimal strings, UUID formats, timestamp formats, etc., and candidate generalization rules are automatically generated accordingly. To ensure that newly generated rules do not negatively impact existing correct merging results, an isolation verification process is performed before formal deployment: candidate generalization rules are applied to validation set traffic within a preset verification time period (e.g., the most recent hour), merging operations are performed according to these rules, and the merging quality is evaluated. For example, this quality evaluation can employ either or a combination of the following two methods: one is a manually labeled evaluation method, where the verification results are manually labeled, and the merging accuracy and false positive rate are calculated; the other is an unsupervised evaluation method, where no manual labeling is required, and the cluster purity and silhouette coefficient of API clusters under the candidate generalization rules are directly calculated. Cluster purity measures the consistency of APIs within the same category, and the silhouette coefficient measures the separation between different categories. If the verification results show that the candidate generalization rule meets the preset index requirements (e.g., accuracy of no less than 95% and false alarm rate of no more than 5% under manual evaluation, or cluster purity and silhouette coefficient exceeding the corresponding threshold under unsupervised evaluation), then the rule is officially included in the interface merging strategy set and pushed to the online traffic parsing module for real-time matching; if the verification fails, the rule is discarded and the exception log is retained for manual analysis.

[0061] Optionally, a strategy version control and automatic rollback mechanism can be maintained. For example, each time the API merging strategy set is updated (including adding, modifying, or deleting rules), the current complete strategy set is saved as an independent strategy version, and metadata such as version number, effective time, and trigger reason are recorded. When a new version strategy is launched, the merging error rate (e.g., unreasonable API aggregation ratios caused by erroneous merging) is continuously monitored. If the merging error rate exceeds a preset alarm threshold, a rollback operation is automatically triggered, restoring the API merging strategy set to the previous stable version and discontinuing the use of problematic versions. This rollback process supports hot switching without requiring a system restart, while retaining exception logs for manual analysis. Through the above mechanism, API merging strategies can be automatically updated as business evolves, and they have self-healing capabilities when strategies fail, thereby significantly reducing manual maintenance costs and ensuring high accuracy and stability for long-term system operation.

[0062] like Figure 2 As shown, Figure 2 The API acquisition process is demonstrated, primarily completed collaboratively by the traffic parsing module and the API merging module, showcasing an architecture that combines online and offline processing. In the online processing phase, the traffic parsing module receives business traffic logs in real time and extracts the API information to be processed. After extraction, it determines whether the API conforms to the existing interface merging strategy: if it does (i.e., a successful match), the corresponding generalized API record is used directly to update API statistics (such as access counts, source IP, etc.), without storing the API in the database. If it does not conform (i.e., a failed match), the relevant information of the API is encapsulated, and a database insert or update operation is performed, storing it as an unmerged API in the database for subsequent processing. In the offline processing phase, the API merging module periodically (e.g., during daily off-peak business periods) reads all unmerged API data from the database, performs similarity analysis and merging operations, and generates a new interface merging strategy after merging, pushing it to the traffic parsing module in the online phase for subsequent real-time matching. This process achieves a closed loop between online matching and offline merging, ensuring both the efficiency of real-time processing and the completeness and accuracy of the merging process.

[0063] like Figure 3 As shown, Figure 3This section demonstrates the specific workflow of the API merging module, specifically the core steps of generalizing and merging unmerged APIs in the offline phase. When the API merging module starts, it first loads preset generalization rules (including default rules such as pure numeric rules, and user-defined wildcard rules) and a merging threshold K. Then, it queries the database for all unmerged APIs, obtaining a set of APIs to be merged. For each API in the set, its path portion is split into multiple path segments using a separator (slash " / "). These segments are then iterated through one by one, checking if each segment conforms to any of the preset generalization rules (e.g., whether it is a pure numeric string, whether it matches a custom wildcard pattern, etc.). If a segment conforms to a preset generalization rule, it is replaced with a wildcard; otherwise, the original segment is retained. After all segments are processed, they are reassembled to generate candidate generalized APIs. These candidate generalized APIs are stored in a Map container as key-value pairs, where the key is the candidate generalized API and the value is the original API set corresponding to that candidate generalized API. For example, the diagram shows the candidate generalized API " / aaa / ". " / ccc" corresponds to four original APIs ( / aaa / 123 / ccc, / aaa / 602 / ccc, etc.), and the candidate generalized API " / a / b / This corresponds to four original APIs ( / a / b / con1, / a / b / con2, etc.). After all APIs to be merged have been traversed, each candidate generalized API in the Map container is judged: if the number of its corresponding original APIs is greater than the merging threshold K, then the merging operation is performed, including deleting the original API record in the database, adding a new generalized API record, and generating the corresponding interface merging strategy; if the number of original APIs is not greater than the threshold K, then they are not merged for the time being, and the original APIs are retained for the next processing. This process achieves accurate identification and effective merging of similar APIs through path splitting, rule matching, aggregation statistics, and threshold judgment.

[0064] like Figure 4 As shown, this embodiment of the disclosure provides an interface information processing device 400, including: Traffic parsing module 41 is used to parse business traffic logs in real time and extract application programming interface (API) to be processed. The interface merging strategy execution module 42 is used to match the API to be processed with the acquired set of interface merging strategies. If the API to be processed matches any interface merging strategy, the API statistics are updated on the generalized API record corresponding to the interface merging strategy. If the matching fails, the API to be processed is stored in the database as an unmerged API. API merging module 43 reads unmerged APIs from the database at a preset trigger time to obtain a set of APIs to be merged; determines the path segment of each API to be merged in the set of APIs to be merged, matches the path segment with a preset generalization rule, replaces the path segment that conforms to the preset generalization rule with a wildcard, and generates candidate generalized APIs; counts the number of original APIs corresponding to each candidate generalized API, and if the number of original APIs is greater than a preset merging threshold, deletes the original APIs corresponding to the candidate generalized APIs from the database, adds a generalized API record corresponding to the candidate generalized APIs to the database, and generates an interface merging strategy corresponding to the candidate generalized APIs, which is then included in the interface merging strategy set.

[0065] In one implementation, the API merging module 43 determines the path segment of each API to be merged in the set of APIs to be merged, including: extracting the path part of each API to be merged in the set of APIs to be merged, splitting the path part according to a preset delimiter, and obtaining multiple path segments.

[0066] In one implementation, the API merging module 43 matches the path segment with preset generalization rules, including: matching the path segment with each default rule and custom rule in the preset generalization rules one by one; if the path segment conforms to any rule in the default rule or the custom rule, then the path segment is determined to be a replaceable path segment, and the replaceable path segment is replaced with a wildcard to generate the candidate generalized API.

[0067] In one implementation, the default rule includes at least one of the following: a pure numeric rule for identifying path segments composed of numeric characters; a hexadecimal string rule for identifying path segments composed of hexadecimal characters with a length conforming to a preset number of digits; a Universally Unique Identifier (UUID) format rule for identifying path segments conforming to the UUID format; and / or, the custom rule is configured by the user and represents the matching pattern of the path segments in the form of a combination of wildcards and fixed strings.

[0068] In one implementation, the API merging module 43 counts the number of original APIs corresponding to each candidate generalized API, including: using the candidate generalized API as the key, querying whether the key corresponding to the candidate generalized API already exists in the aggregation container; if it does not exist, creating a new set of original APIs, adding the original APIs to the set, and storing the key corresponding to the candidate generalized API and the set of original APIs in the aggregation container as key-value pairs; if it already exists, adding the original APIs to the set of original APIs corresponding to the key in the aggregation container; after traversing all APIs to be merged in the set of APIs to be merged, obtaining the number of APIs in the set of original APIs corresponding to each candidate generalized API from the aggregation container, as the number of original APIs corresponding to each candidate generalized API.

[0069] In one implementation, the API merging module is further configured to, after determining that the number of original APIs is greater than a preset merging threshold and before performing deletion and addition operations, use the request method, parameter name set, response data structure, and call context of each original API in the original API set corresponding to the candidate generalized API as input parameters, and use a pre-trained semantic model to map the input parameters into semantic vectors to obtain the semantic vector corresponding to each original API; based on the semantic vectors and the path structure of the candidate generalized APIs, calculate the semantic similarity and structural similarity between each original API in the original API set, and perform weighted fusion of the semantic similarity and structural similarity to obtain a comprehensive similarity score; when the comprehensive similarity score exceeds a preset dynamic threshold, determine that the original API set corresponding to the candidate generalized API can perform the deletion and addition operations; the preset dynamic threshold is adaptively adjusted according to the business module to which the original API belongs.

[0070] In one implementation, the API merging module is further configured to: statistically analyze the proportion of newly added APIs that cannot match any interface merging strategy within a preset time period to obtain a matching failure rate; when the matching failure rate exceeds a corresponding preset monitoring threshold, trigger an incremental learning task to analyze the set of APIs that have not been merged to obtain candidate generalization rules; apply the candidate generalization rules to the verification set traffic within a preset verification time period to verify the merging quality; if the verification determines that the candidate generalization rules meet the preset indicator requirements, then the candidate generalization rules are included in the interface merging strategy set.

[0071] The specific implementation process of the functions and roles of each module in the above-mentioned device 400 can be found in the implementation process of the corresponding steps in the above-mentioned interface information processing method, and will not be repeated here.

[0072] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this disclosure according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0073] Based on the same technical concept, this disclosure also provides an electronic device 500, referring to... Figure 5 The diagram shown is a schematic representation of the structure of an electronic device according to an exemplary embodiment of this disclosure, comprising: The processor 510, memory 520, and bus 530 are included. The memory 520 is used to store execution instructions and includes main memory 521 and external memory 522. The main memory 521, also known as internal memory, is used to temporarily store the operation data in the processor 510 and the data exchanged with external memory 522 such as hard disk. The processor 510 exchanges data with external memory 522 through main memory 521.

[0074] In this embodiment, the memory 520 is specifically used to store application code that executes the scheme of this disclosure, and its execution is controlled by the processor 510. That is, when the electronic device 500 is running, the processor 510 communicates with the memory 520 through the bus 530, or the processor 510 communicates with the memory 520 through other means, so that the processor 510 executes the application code stored in the memory 520, and then executes the steps of the interface information processing method described in any of the foregoing embodiments.

[0075] The memory 520 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0076] Processor 510 may be an integrated circuit chip with signal processing capabilities. The aforementioned processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor.

[0077] It is understood that the structures illustrated in the embodiments of this disclosure do not constitute a specific limitation on the electronic device 500. In other embodiments of this disclosure, the electronic device 500 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0078] This disclosure also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the interface information processing method described in the above method embodiments. The storage medium can be a volatile or non-volatile computer-readable storage medium.

[0079] This disclosure also provides a computer program product, which stores a computer program. When the computer program is run by a processor, it executes the steps of the interface information processing method provided in any of the above embodiments of this disclosure. For details, please refer to the above method embodiments, which will not be repeated here.

[0080] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium, which can be a volatile or non-volatile computer-readable storage medium. In another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0081] Furthermore, embodiments of the subject matter and functional operation described in this specification can be implemented in the following ways: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or combinations thereof. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory program carrier for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. Alternatively or additionally, program instructions may be encoded on artificially generated propagation signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information and transmit it to a suitable receiving device for execution by the data processing apparatus. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or combinations thereof.

[0082] The processing and logic flows described in this specification can be executed by one or more programmable computers that execute one or more computer programs to perform corresponding functions by operating on input data and generating output. The processing and logic flows can also be executed by dedicated logic circuits—such as field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs), and the device can also be implemented as dedicated logic circuits.

[0083] Suitable computers for executing computer programs include, for example, general-purpose and / or special-purpose microprocessors, or any other type of central processing unit. Typically, the central processing unit receives instructions and data from read-only memory and / or random access memory. The basic components of a computer include a central processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as disks, magneto-optical disks, or optical disks, or the computer will be operatively coupled to such mass storage devices to receive data from or transfer data to them, or both. However, a computer is not required to have such devices. Furthermore, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device such as a Universal Serial Bus (USB) flash drive, to name a few.

[0084] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. Processors and memory may be supplemented by or incorporated into dedicated logic circuitry.

[0085] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily intended to describe features of specific embodiments of a particular invention. Certain features described in the various embodiments herein may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in various embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation thereof.

[0086] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or requiring all illustrated operations to be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0087] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings are not necessarily shown in a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0088] The above description is merely a preferred embodiment of this disclosure and is not intended to limit this disclosure. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for processing interface information, characterized in that, The method includes: Real-time analysis of business traffic logs to extract application programming interface (API) data to be processed; The API to be processed is matched with the obtained set of interface merging strategies. If the API to be processed matches any interface merging strategy, the API statistics are updated on the generalized API record corresponding to any interface merging strategy. If the matching fails, the API to be processed is stored in the database as an unmerged API. At a preset trigger time, unmerged APIs are read from the database to obtain a set of APIs to be merged; Determine the path segments of each API to be merged in the set of APIs to be merged, match the path segments with preset generalization rules, and replace the path segments that conform to the preset generalization rules with wildcards to generate candidate generalized APIs. The number of original APIs corresponding to each candidate generalized API is counted. If the number of original APIs is greater than a preset merging threshold, the original APIs corresponding to the candidate generalized APIs are deleted from the database, a new generalized API record corresponding to the candidate generalized API is added to the database, and an interface merging strategy corresponding to the candidate generalized API is generated and included in the interface merging strategy set.

2. The method according to claim 1, characterized in that, Determining the path segments for each API in the set of APIs to be merged includes: Extract the path portion of each API to be merged from the set of APIs to be merged, and split the path portion according to a preset delimiter to obtain multiple path segments.

3. The method according to claim 1, characterized in that, Matching the path segments with preset generalization rules includes: The path segment is matched one by one with each default rule and custom rule in the preset generalization rules. If the path segment conforms to any rule in the default rule or the custom rule, the path segment is determined to be a replaceable path segment. The replaceable path segment is replaced with a wildcard to generate the candidate generalized API.

4. The method according to claim 3, characterized in that, The default rules include at least one of the following: pure numeric rules, used to identify path segments composed of numeric characters; hexadecimal string rules, used to identify path segments composed of hexadecimal characters with a length conforming to a preset number of digits; universally unique identifier (UUID) format rules, used to identify path segments conforming to the universally unique identifier format; and / or, The custom rules are configured by the user and represent the matching pattern of path segments in the form of a combination of wildcards and fixed strings.

5. The method according to claim 1, characterized in that, The counting of the original APIs corresponding to each candidate generalized API includes: Using the candidate generalized API as the key, query whether the key corresponding to the candidate generalized API already exists in the aggregation container; If it does not exist, a new original API set is created, the original API is added to the original API set, and the key corresponding to the candidate generalized API and the original API set are stored in the aggregation container as key-value pairs; if it already exists, the original API is added to the original API set corresponding to the key in the aggregation container. After traversing all APIs in the API set to be merged, the number of APIs in the original API set corresponding to each candidate generalized API is obtained from the aggregation container, which is used as the number of original APIs corresponding to each candidate generalized API.

6. The method according to claim 1, characterized in that, After determining that the number of original APIs is greater than a preset merging threshold, and before performing deletion and addition operations, the process also includes: Using the request method, parameter name set, response data structure, and call context of each original API in the original API set corresponding to the candidate generalized API as input parameters, the input parameters are mapped into semantic vectors using a pre-trained semantic model to obtain the semantic vector corresponding to each original API. Based on the semantic vector and the path structure of the candidate generalized API, the semantic similarity and structural similarity between each original API in the original API set are calculated respectively. The semantic similarity and structural similarity are then weighted and fused to obtain a comprehensive similarity score. When the overall similarity score exceeds a preset dynamic threshold, it is determined that the original API set corresponding to the candidate generalized API can perform the deletion and addition operations; the preset dynamic threshold is adaptively adjusted according to the business module to which the original API belongs.

7. The method according to claim 1, characterized in that, Also includes: The matching failure rate is calculated by determining the percentage of newly added APIs that cannot be matched with any interface merging strategy within a preset time period. When the matching failure rate exceeds the corresponding preset monitoring threshold, an incremental learning task is triggered to analyze the unmerged API set and obtain candidate generalization rules. The candidate generalization rule is applied to the verification set traffic within a preset verification time period for merging quality verification. If the candidate generalization rule is verified to meet the preset indicator requirements, then the candidate generalization rule is included in the interface merging strategy set.

8. An interface information processing device, characterized in that, include: The traffic parsing module is used to parse business traffic logs in real time and extract the application programming interface (API) to be processed. The interface merging strategy execution module is used to match the API to be processed with the obtained set of interface merging strategies. If the API to be processed matches any interface merging strategy, the API statistics information is updated on the generalized API record corresponding to any interface merging strategy. If the matching fails, the API to be processed will be stored in the database as an unmerged API. The API merging module reads unmerged APIs from the database at a preset trigger time to obtain a set of APIs to be merged. Determine the path segments of each API to be merged in the set of APIs to be merged, match the path segments with preset generalization rules, and replace the path segments that conform to the preset generalization rules with wildcards to generate candidate generalized APIs. The number of original APIs corresponding to each candidate generalized API is counted. If the number of original APIs is greater than a preset merging threshold, the original APIs corresponding to the candidate generalized APIs are deleted from the database, a new generalized API record corresponding to the candidate generalized API is added to the database, and an interface merging strategy corresponding to the candidate generalized API is generated and included in the interface merging strategy set.

9. An electronic device, characterized in that, The method includes a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and the processor is used to execute the machine-readable instructions stored in the memory. When the machine-readable instructions are executed by the processor, the processor performs the steps of the interface information processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Includes instructions stored thereon, wherein, when the instructions are executed by a processor, the interface information processing method as described in any one of claims 1-7 is executed.

Images