Link list-based interface fusion method and device, storage medium and computer device

Abstract

This invention discloses a linked list-based interface fusion method, apparatus, storage medium, and computer device, relating to the field of security monitoring technology. The method includes: obtaining an interface monitoring list of the system to be monitored, wherein the interface monitoring list records multiple interface request paths of the system to be monitored; merging multiple interface request paths with the same function according to a preset interface request path merging rule to obtain at least one merged request path; and storing the merged request path in a database in the form of a linked list. This method can effectively reduce the space occupied by interface request paths, improve the space utilization of the database, and thus improve the efficiency of interface request path statistics and analysis.

Description

Technical Field

[0001] This invention relates to the field of security monitoring technology, and in particular to a linked list-based interface fusion method, apparatus, storage medium, and computer equipment. Background Technology

[0002] Application Programming Interface (API) call monitoring is a way to monitor and analyze API call behavior in real time. It helps developers and system administrators understand API usage, performance metrics, and potential problems. By monitoring API calls, performance bottlenecks, errors, and anomalies can be identified and resolved promptly, thereby improving system reliability and stability.

[0003] When monitoring system interfaces, a large number of repetitive interface request paths may be detected. For example, for a request to retrieve user IDs, if the client requests several user IDs, several interface request paths will be detected. In existing technologies, all monitored interface request paths are stored in a database for subsequent statistical analysis. However, a large number of interface request paths consumes significant database space, hindering subsequent statistical and analytical work. Summary of the Invention

[0004] In view of this, this application provides an interface fusion method, apparatus, storage medium and computer device based on linked lists. The main purpose is to solve the technical problem that a large number of interface request paths occupy a lot of database space and are not conducive to the statistics and analysis of interface request paths.

[0005] According to a first aspect of the present invention, a linked list-based interface fusion method is provided, the method comprising:

[0006] Obtain the interface monitoring list of the system to be monitored, wherein the interface monitoring list records multiple interface request paths of the system to be monitored;

[0007] According to the preset interface request path merging rules, multiple interface request paths with the same function are merged to obtain at least one merged request path.

[0008] The fusion request path is stored in the database as a linked list.

[0009] According to a second aspect of the present invention, a linked list-based interface fusion apparatus is provided, the apparatus comprising:

[0010] The request path acquisition module is used to acquire the interface monitoring list of the system to be monitored, wherein the interface monitoring list records multiple interface request paths of the system to be monitored.

[0011] The request path fusion module is used to merge multiple interface request paths with the same function according to the preset interface request path merging rules, so as to obtain at least one merged request path.

[0012] The request path storage module is used to store the fusion request path in the database in the form of a linked list.

[0013] According to a third aspect of the present invention, a storage medium is provided on which a computer program is stored, which, when executed by a processor, implements the above-described linked list-based interface fusion method.

[0014] According to a fourth aspect of the present invention, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described linked list-based interface fusion method.

[0015] This invention provides an interface fusion method, apparatus, storage medium, and computer device based on a linked list. First, multiple interface request paths of the system to be monitored are acquired. Then, according to preset interface request path merging rules, multiple interface request paths with the same function are merged to obtain at least one merged request path. Finally, the merged request path is stored in a database in the form of a linked list. This method, by merging multiple interface request paths with the same function to obtain at least one merged request path and storing it in the database as a linked list, can effectively reduce the space occupied by interface request paths, improve the space utilization of the database, and thus improve the efficiency of interface request path statistics and analysis.

[0016] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0018] Figure 1 The diagram illustrates a flowchart of an interface fusion method based on a linked list provided by an embodiment of the present invention.

[0019] Figure 2 The diagram shows a schematic of a linked list-based interface fusion device provided by an embodiment of the present invention. Detailed Implementation

[0020] The present invention will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the present application can be combined with each other.

[0021] In one embodiment, such as Figure 1 As shown, a linked list-based interface fusion method is provided. Taking the application of this method to computer devices such as servers as an example, the method includes the following steps:

[0022] 101. Obtain the interface monitoring list of the system to be monitored. The interface monitoring list records multiple interface request paths of the system to be monitored.

[0023] The interface request path (hereinafter referred to as the request path) refers to the path through which a client requests access to a server. The client submits the request path to access a specific resource on the server; therefore, the request path typically consists of two parts: the resource path and the resource name. The dividing line between the resource path and the resource name is the last forward slash in the request path. That is, the part before the forward slash is called the resource path, and the part after the forward slash is called the resource name. For example:

[0024] The API request path is: http: / / localhost:8888 / 01-primary / some.do

[0025] The resource path is then: http: / / localhost:8888 / 01-primary

[0026] The resource name is: some.do

[0027] Furthermore, based on whether a request path can uniquely locate a resource, request paths can be divided into two categories: absolute paths and relative paths. An absolute path is a path that can uniquely locate a resource. In Web (World Wide Area Network) applications, paths that begin with a request protocol are generally absolute paths. Absolute paths are represented in URL (Uniform Resource Locator) form. A relative path is a path that cannot uniquely locate a resource on its own. However, if it is combined with a reference path, it can be converted into an absolute path that can locate the resource; such a path is called a relative path. In Web applications, paths that do not begin with a request protocol are generally relative paths. Relative paths are represented in URI (Uniform Resource Identifier) ​​form. In this embodiment, the interface request path can be either an absolute path or a relative path; this embodiment does not impose specific restrictions.

[0028] Specifically, the system to be monitored refers to a system whose interface calls are authorized for external monitoring. For example, the system to be monitored could be an enterprise's internal customer management system, financial system, document management system, etc. Furthermore, by monitoring the endpoints (apiEndPoint, a URL address that defines the exposed application interface) of each interface of each system to be monitored, the request paths of all interfaces under that monitored system can be monitored. Then, all monitored interface request paths can be stored in an interface monitoring list for further processing.

[0029] 102. According to the preset interface request path merging rules, multiple interface request paths with the same function are merged to obtain at least one merged request path.

[0030] Multiple interface request paths with the same function refer to multiple interface request paths that implement the same data request function. The requested data may or may not be the same. For example, two interface request paths may both request user IDs, but the user IDs requested by the two interface request paths are different. In this case, the two interface request paths can be considered to have the same function. As another example, two interface request paths may be used to request a user list and a user ID respectively. In this case, regardless of whether the data requested by the two interface request paths is the same, the two interface request paths do not have the same function.

[0031] Specifically, for any two interface request paths, if they have the same function, their resource paths should be identical or very similar. Using this characteristic, interface request path merging rules can be set, and these rules can be used to perform a step-by-step similarity assessment of the resource paths of each pair of interface request paths in the interface monitoring list at each level, thus obtaining the similarity assessment results for each pair of interface request paths in the interface monitoring list. Furthermore, based on the similarity assessment results of each pair of interface request paths in the interface monitoring list, it can be determined whether multiple similar interface paths meet the interface merging conditions in the preset interface request path merging rules. If these conditions are met, multiple interface request paths can be merged to obtain at least one merged request path.

[0032] In this embodiment, when merging multiple interface request paths, the protocols and domain names in the resource paths can be merged without merging them. Only the resource paths and resource names, excluding the protocols and domain names, are merged. This is because the protocols and domain names of the system under monitoring are usually fixed, making their merging meaningless and consuming database storage space. Furthermore, merging resource paths refers to combining paths at the same level from multiple interface request paths into a single path; merging resource names refers to merging the resource names from multiple interface request paths into a single resource name. This embodiment reduces the database space occupied by interface request paths by merging them.

[0033] 103. Store the fusion request path in the database as a linked list.

[0034] Linked lists, also known as linked storage structures or singly linked lists, are a type of linear storage structure. Linked lists do not restrict the physical storage state of data; the physical storage location of data elements stored in a linked list is random. Therefore, using linked lists to store data can improve the space utilization of a database.

[0035] Specifically, fusion request paths typically have multiple levels. Taking the request path in step 101 as an example, this request path includes a resource path and a resource name. Based on this, the fusion request path after fusion processing also includes at least two levels: resource path and resource name. Furthermore, for some fusion request paths, their resource paths often have multiple levels, with each level separated by a forward slash. Correspondingly, a linked list linear storage structure can be used to store data with multiple levels. Each node in the linked list can store the resource path or resource name of one level in the fusion request path. Each node in the linked list can point to the next node through an address pointer, thus forming the hierarchical structure of the fusion request path. This embodiment utilizes a linked list storage structure to store the fusion request path, which completely preserves the hierarchical structure of the fusion request path. Moreover, after fusion processing, the number of nodes occupied by the fusion request path is significantly reduced compared to before fusion processing. Therefore, storing the fusion request path using a linked list structure can effectively reduce the database space occupancy rate. Furthermore, the storage structure of the linked list itself also determines that the space utilization rate of the fusion request path is relatively high.

[0036] The linked list-based interface fusion method provided in this embodiment first obtains multiple interface request paths of the system to be monitored. Then, according to preset interface request path merging rules, it merges multiple interface request paths with the same function to obtain at least one merged request path. Finally, it stores the merged request path in the database in the form of a linked list. This method, by merging multiple interface request paths with the same function to obtain at least one merged request path and storing it in the database as a linked list, can effectively reduce the space occupied by interface request paths, improve the space utilization of the database, and thus improve the efficiency of interface request path statistics and analysis.

[0037] In one embodiment, step 102 can be implemented by the following method: extracting the resource path and resource name of each interface request path, then calculating the similarity of the resource paths of any two interface request paths, and determining whether any two interface request paths are similar request paths based on the similarity of the resource paths. If there are multiple interface request paths that are similar to each other, then the multiple interface request paths are fused to obtain at least one fused request path.

[0038] For example, when monitoring the endpoints of all interfaces under a certain system, the following interface request paths were detected: http: / / hostname / api / user / get / 1; http: / / hostname / api / user / get / 2; http: / / hostname / api / user / get / 3; http: / / hostname / api / user / get / 4; http: / / hostname / api / user / get / 5; http: / / hostname / api / user / get / 6. By extracting the resource paths and resource names of the above multiple interface request paths and performing a similarity judgment on the resource paths of each pair of interface request paths, it can be found that the resource paths of the above six interface request paths are the same, all being / api / user / get / (the protocol and domain name do not need to be merged). Although the resource names of the above six interface request paths are different from each other, it can still be determined that the above six interface request paths are similar to each other. Therefore, the above six interface request paths can be merged to obtain a merged request path: / api / user / get / {id}.

[0039] The above embodiment calculates the similarity of resource paths between any two interface request paths from multiple interface request paths, and determines whether there are multiple interface request paths that are similar to each other based on the similarity of resource paths between each pair of interface request paths. Then, it merges these multiple interface request paths to obtain at least one merged request path. This method can effectively determine whether multiple interface request paths are multiple interface request paths with the same function, thereby improving the accuracy of interface request path merging.

[0040] In one embodiment, the method for determining whether any two interface request paths are similar request paths in the above embodiment can be implemented through the following steps: For any two interface request paths, determine whether the base path and the sub-paths at each level of the two interface request paths are the same. If the base path of the two interface request paths is the same, and the sub-paths at each level of the two interface request paths are the same, then the two interface request paths are determined to be similar request paths.

[0041] In this context, the base path refers to the highest-level path in the resource path besides the protocol and domain name. Following the base path, sub-paths at each level are sequentially separated by forward slashes, with each sub-path after a forward slash being one level lower than the sub-path before the forward slash. For example, in the API request path `http: / / hostname / api / user / get / 1`, the base path is `api`, the next level sub-path is `user`, and the next level sub-path is `get`, where `hostname` is the domain name and `1` is the resource name. In this embodiment, determining whether the base paths of two API request paths are the same means checking if the string corresponding to the base path of one API request path is exactly the same as the string corresponding to the base path of the other API request path. Furthermore, determining whether the sub-paths at each level of two API request paths are the same means checking if the string corresponding to a sub-path at one level of one API request path is exactly the same as the string corresponding to a sub-path at the same level of the other API request path.

[0042] For example, consider the following two API request paths: http: / / hostname / api / user / get / 1 and http: / / hostname / api / user / get / 2. To determine whether these two API request paths are similar, we can first determine whether the base paths of the two API request paths are the same, and then determine whether the sub-paths at each level of the two API request paths are the same. By checking, we can find that the base paths of the two API request paths are the same, and the sub-paths at each level of the two API request paths are also the same. Therefore, we can determine that the above two API request paths are similar request paths.

[0043] The above embodiments determine whether two interface request paths are similar by judging whether their base paths and sub-paths at each level are the same. This can accurately determine whether any two interface request paths have the same function, thereby improving the accuracy of interface request path merging.

[0044] In one embodiment, the method for determining whether any two interface request paths are similar request paths in the above embodiment can also be implemented through the following steps: For any two interface request paths, determine whether the base paths of the two interface request paths are the same. If the base paths of the two interface request paths are the same, then determine whether the sub-paths of the two interface request paths are the same at each level. If the sub-paths of the two interface request paths are different at any level, then calculate the similarity of the sub-paths of the two interface request paths at that level. If the similarity of the sub-paths of the two interface request paths at that level is greater than a preset similarity threshold, and the sub-paths at all levels before that level are the same and / or the similarity of the sub-paths at all levels before that level is greater than the similarity threshold, then the two interface request paths are determined to be similar request paths.

[0045] In the above embodiments, calculating the similarity of sub-paths at any level of two interface request paths refers to calculating the string similarity between the string corresponding to the sub-path of one interface request path at that level and the string corresponding to the sub-path of another interface request path at that level. Generally, when the sub-paths of two interface request paths at a certain level are very similar, and the base paths of the two interface request paths are the same, and the sub-paths before that level are also the same or very similar, it means that the data request functions of the two interface request paths are the same. Based on this characteristic, it can be determined whether the two interface request paths are similar request paths.

[0046] For example, consider the following two API request paths: http: / / hostname / api / user / get / aa1992bb10aa12 / aa1 and http: / / hostname / api / user / get / aa1992bb10aa21 / aa2. To determine if these two API request paths are similar, we can first check if their base paths are the same. After confirming the base paths are the same, we can then check if their sub-paths at each level are the same. The results show that the base paths are the same, the similarity of their sub-paths at the third level is greater than a preset similarity threshold, and their sub-paths at the first and second levels are identical. Therefore, we can conclude that the two API request paths are similar.

[0047] The above embodiments calculate the similarity of the sub-paths of two interface request paths at any level, and determine whether the two interface request paths are similar request paths by the similarity of the two sub-paths. This can avoid the problem of multiple interface request paths with the same function being missed in merging, thereby improving the accuracy of interface request path fusion.

[0048] In one embodiment, the method for calculating the similarity of sub-paths at any level of two interface request paths in the above embodiment can be implemented through the following steps: First, perform word segmentation on the two sub-paths of the two interface request paths at the same level; then calculate the word frequency and order of each word segmentation result of the two sub-paths; then determine the word frequency vectors of the two sub-paths based on the word frequency of each word segmentation result of the two sub-paths; and then perform weighted processing on the word frequency vectors of the two sub-paths based on the order of each word segmentation result of the two sub-paths; finally, calculate the similarity of the word frequency vectors of the two sub-paths using a preset similarity calculation formula to obtain the similarity of the sub-paths of the two interface request paths at the same level.

[0049] For example, two interface request paths have two sub-paths at the same level, namely

aa1992bb10aa12

aa1992bb10aa21

[0050]

aa1992bb10aa12

[0051]

aa1992bb10aa21

[0052] Then, by calculating the word frequencies of each segmentation result of the two sub-paths, and determining the word frequency vectors of the two sub-paths based on the word frequencies of each segmentation result of the two sub-paths, the following results can be obtained:

[0053]

aa1992bb10aa12

[0054]

aa1992bb10aa21

[0055] Furthermore, the word frequency vectors of the two sub-paths can be weighted according to the order of their word segmentation results. For example, the word segmentation result "aa" can be weighted to 3 or 4, etc. Finally, using a preset similarity calculation formula, such as the cosine similarity formula, the similarity of the word frequency vectors of the two sub-paths can be calculated, yielding a similarity of 87.5% for the sub-paths of the two interface request paths at this level. Therefore, it can be determined that the similarity between the two sub-paths of the two interface request paths at this level is 87.5%, and also that the similarity is greater than the preset similarity threshold of 85%.

[0056] The above embodiment obtains the word frequency vectors of two sub-paths at the same level of two interface request paths by performing word segmentation and weighting, and calculates the similarity between the word frequency vectors of the two sub-paths to obtain the similarity between the sub-paths of the two interface request paths at the same level. This can improve the accuracy of sub-path similarity judgment, thereby improving the accuracy of interface request path fusion.

[0057] In one embodiment, the method for merging multiple interface request paths into a merged request path described above can be implemented through the following steps: If multiple interface request paths are similar to each other, a merged request path is created, and then the base path of the multiple interface request paths is determined as the base path of the merged request path. Further, if the sub-paths of the multiple interface request paths are the same at any level, then the sub-paths at that level are determined as the sub-paths of the merged request path at that level; if the sub-paths of the multiple interface request paths are different at any level, then a preset common sub-path is determined as the sub-path of the merged request path at that level. Finally, the merged request path is obtained based on the base path of the merged request path and the sub-paths at each level.

[0058] For example, consider the following three API request paths: http: / / hostname / api / user / get / aa1992bb10aa12 / aa1, http: / / hostname / api / user / get / aa1992bb10aa21 / aa2, and http: / / hostname / api / user / get / aa1992bb10aa21 / aa3. Assuming these three request paths are similar to each other, a merged request path can be created. The base path of this merged request path is api, the next level sub-path is user, the next level sub-path is get, and the next level sub-path is the preset general sub-path {param}. Finally, the resource names for the merged request paths can be the individual resource names for each interface request path: aa1, aa2, and aa3, or a preset general resource name: {aaid}. The resulting merged request paths are / api / user / get / {param} / {aaid}, or / api / user / get / {param} / aa1, / api / user / get / {param} / aa2, and / api / user / get / {param} / aa3.

[0059] In the above embodiments, by merging multiple interface request paths to obtain at least one merged request path, the space occupied by storing interface request paths in the database can be reduced, thereby improving the efficiency of interface request path analysis and statistics.

[0060] In one embodiment, step 103 can be implemented as follows: For any fusion request path, first create a head pointer and a first meta node, and use the first meta node to store the base path of the fusion request path, wherein the head pointer points to the first meta node. Then, repeat the following steps until all levels of sub-paths of the fusion request path have been stored: create a node, and use the node to store the sub-path of one level of the fusion request path, and then set the node as a child node of the previous node according to the level of the sub-path.

[0061] For example, consider the fusion request path described in the previous embodiment: / api / user / get / {param} / {aaid}. For this fusion method, the fusion request path can be stored as follows: the basic path api is stored in the first element node, and then user, get, {param}, and {aaid} are stored sequentially in newly created nodes, establishing a hierarchical relationship between each node and the previous node. Specifically, the node storing user is a child node of the first element node, the node storing get is a child node of the node storing user, the node storing {param} is a child node of the node storing get, and the node storing {aaid} is a child node of the node storing {param}. This method allows for the storage of a fusion request path in the database.

[0062] Furthermore, taking the fusion request path described in the previous embodiment as an example: / api / user / get / {param} / aa1, / api / user / get / {param} / aa2, and / api / user / get / {param} / aa3. For this fusion method, the fusion request path can be stored as follows: the basic path api is stored in the first element node, and then user, get, {param}, aa1, aa2, and aa3 are sequentially stored in newly created nodes, establishing a hierarchical relationship between each node and the previous node. Specifically, the node storing user is a child node of the first element node, the node storing get is a child node of the node storing user, the node storing {param} is a child node of the node storing get, the node storing aa1 is a child node of the node storing {param}, the node storing aa2 is another child node of the node storing {param}, and the node storing aa3 is the rightmost child node of the node storing {param}. This method also enables the storage of a fusion request path in the database.

[0063] In the above embodiments, after multiple interface request paths are merged, they can be stored in the database as a linked list, thereby reducing the number of nodes in the linked list and reducing the storage space occupied by the interface request paths. In addition, the linked list storage structure itself has a relatively high space utilization rate for the database, thus effectively increasing the storage capacity of the interface request paths.

[0064] In one embodiment, multiple interface request paths can also be merged manually. That is, if a technician determines that multiple interface request paths have the same function, the computer device can respond to the path merging operation by sequentially merging the resource paths and resource names at each level of the multiple interface request paths to obtain at least one merged request path. Then, the merged request paths are stored in the database in the form of a linked list, thereby reducing the database's space occupancy and improving its space utilization.

[0065] Furthermore, as Figure 1 The specific implementation of the method shown in this embodiment provides an interface fusion device based on a linked list, such as... Figure 2 As shown, the device includes: a request path acquisition module 31, a request path fusion module 32, and a request path storage module 33.

[0066] The request path acquisition module 31 can be used to acquire the interface monitoring list of the system to be monitored, wherein the interface monitoring list records multiple interface request paths of the system to be monitored.

[0067] The request path fusion module 32 can be used to merge multiple interface request paths with the same function according to the preset interface request path merging rules, so as to obtain at least one merged request path.

[0068] The request path storage module 33 can be used to store the fusion request path in the form of a linked list in the database.

[0069] In specific application scenarios, the request path fusion module 32 can be used to extract the resource path and resource name of each interface request path; calculate the similarity of the resource paths of any two interface request paths, and determine whether any two interface request paths are similar request paths based on the similarity of the resource paths; if there are multiple interface request paths that are similar to each other, then the multiple interface request paths are fused to obtain at least one fused request path.

[0070] In specific application scenarios, the request path fusion module 32 can be used to determine whether the base paths of any two interface request paths are the same; if the base paths of the two interface request paths are the same, then it is determined whether the sub-paths of the two interface request paths are the same at each level; if the sub-paths of the two interface request paths are different at any level, then the similarity of the sub-paths of the two interface request paths at that level is calculated; if the similarity of the sub-paths of the two interface request paths at that level is greater than a preset similarity threshold, and the sub-paths at all levels before that level are the same and / or the similarity of the sub-paths at all levels before that level is greater than the similarity threshold, then the two interface request paths are determined to be similar request paths.

[0071] In a specific application scenario, the request path fusion module 32 can be used to perform word segmentation on two sub-paths of the two interface request paths at the same level; calculate the word frequency and order of each word segmentation result of the two sub-paths; determine the word frequency vectors of the two sub-paths based on the word frequency of each word segmentation result of the two sub-paths, and perform weighted processing on the word frequency vectors of the two sub-paths based on the order of each word segmentation result of the two sub-paths; calculate the similarity of the word frequency vectors of the two sub-paths using a preset similarity calculation formula, and obtain the similarity of the sub-paths of the two interface request paths at the same level.

[0072] In a specific application scenario, the request path fusion module 32 can be used to determine whether the base path and the sub-paths at each level of any two interface request paths are the same; if the base path of the two interface request paths is the same, and the sub-paths at each level of the two interface request paths are the same, then the two interface request paths are determined to be similar request paths.

[0073] In specific application scenarios, the request path fusion module 32 can be used to: create a fused request path if multiple interface request paths are similar to each other; determine the base path of the multiple interface request paths as the base path of the fused request path; if the sub-paths of the multiple interface request paths are the same at any level, determine the sub-path of that level as the sub-path of the fused request path at that level; if the sub-paths of the multiple interface request paths are different at any level, determine the preset general sub-path as the sub-path of the fused request path at that level; and obtain the fused request path based on the base path of the fused request path and the sub-paths of each level.

[0074] In a specific application scenario, the request path storage module 33 can be used to create a header pointer and a first element node for any one of the fusion request paths, and use the first element node to store the base path of the fusion request path, with the header pointer pointing to the first element node; and repeatedly execute the following steps until all levels of sub-paths of the fusion request path have been stored: create a node, and use the node to store a level of sub-paths of the fusion request path, and set the node as a child node of the previous node according to the level of the sub-path.

[0075] It should be noted that other corresponding descriptions of the functional units involved in the linked list-based interface fusion device provided in this embodiment can be found in the corresponding descriptions of the above embodiments, and will not be repeated here.

[0076] Based on the methods shown in the above embodiments, this embodiment also provides a storage medium storing a computer program that, when executed by a processor, implements the linked list-based interface fusion method as described in the above embodiments.

[0077] Based on this understanding, the technical solution of this application can be embodied in the form of a software product. The software product to be identified can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, or portable hard drive), including several instructions to cause a computer device (such as a personal computer, server, or network device) to execute the methods described in the various implementation scenarios of this application.

[0078] Based on the above, Figure 1 The method shown, and Figure 2 The illustrated embodiment of the linked list-based interface fusion device, in order to achieve the above objectives, also provides a linked list-based interface fusion computer device, which can be a personal computer, server, smartphone, tablet computer, smartwatch, or other network device, etc. The computer device includes a storage medium and a processor; the storage medium is used to store computer programs and an operating system; the processor is used to execute the computer programs to implement the methods described in the above embodiments.

[0079] Optionally, the computer device may also include internal memory, a communication interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, a display screen, and input devices such as a keyboard. The communication interface may also include a USB interface, a card reader interface, etc. The network interface may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0080] Those skilled in the art will understand that the computer device structure for recognizing operational actions provided in this embodiment does not constitute a limitation on the computer device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0081] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the aforementioned computer hardware and the software resources to be identified, supporting the operation of information processing programs and other software and / or programs to be identified. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing computer device.

[0082] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware platforms, or it can be implemented in hardware. By applying the technical solution of this application, multiple interface request paths of the system to be monitored are first obtained. Then, according to the preset interface request path merging rules, multiple interface request paths with the same function are merged to obtain at least one merged request path. Finally, the merged request path is stored in the database in the form of a linked list. Compared with the prior art, the above method can reduce the space occupied by interface request paths, improve the space utilization of the database, and improve the efficiency of statistical analysis of interface request paths.

[0083] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application. Those skilled in the art will understand that the modules in the apparatus of the embodiment can be distributed within the apparatus of the embodiment as described, or can be modified to be located in one or more apparatuses different from this embodiment. The modules of the above-described embodiment can be combined into one module, or further divided into multiple sub-modules.

[0084] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of any particular implementation scenario. The above disclosures are merely a few specific implementation scenarios of this application; however, this application is not limited thereto, and any variations conceived by those skilled in the art should fall within the protection scope of this application.

Claims

1. A linked list-based interface fusion method, characterized in that, The method includes: Obtain the interface monitoring list of the system to be monitored, wherein the interface monitoring list records multiple interface request paths of the system to be monitored; According to the preset interface request path merging rules, multiple interface request paths with the same function are merged to obtain at least one merged request path. The fusion request path is stored in the database as a linked list; The step of merging multiple interface request paths with the same function according to a preset interface request path merging rule to obtain at least one merged request path includes: Extract the resource path and resource name of each of the interface request paths; For any two of the aforementioned interface request paths, determine whether the base paths of the two interface request paths are the same; If the base paths of the two interface request paths are the same, then determine whether the sub-paths of the two interface request paths are the same at each level. If the sub-paths of the two interface request paths are different at any level, then the similarity of the sub-paths of the two interface request paths at that level is calculated. If the similarity of the sub-paths of two interface request paths at the same level is greater than a preset similarity threshold, and the sub-paths at all levels before the current level are the same and / or the similarity of the sub-paths at all levels before the current level is greater than the similarity threshold, then the two interface request paths are determined to be similar request paths. If multiple interface request paths are similar to each other, then the multiple interface request paths are merged to obtain at least one merged request path.

2. The method according to claim 1, characterized in that, The calculation of the similarity of the sub-paths of the two interface request paths at the same level includes: Perform word segmentation on the two sub-paths of the two interface request paths that are at the same level; Calculate the word frequency and sort order of each word segmentation result for the two sub-paths; Based on the word frequencies of each word segmentation result of the two sub-paths, the word frequency vectors of the two sub-paths are determined, and the word frequency vectors of the two sub-paths are weighted according to the order of the word segmentation results of the two sub-paths. The similarity of the word frequency vectors of the two sub-paths is calculated using a preset similarity calculation formula to obtain the similarity of the sub-paths of the two interface request paths at the same level.

3. The method according to claim 1, characterized in that, The step of calculating the similarity of resource paths between any two interface request paths, and determining whether any two interface request paths are similar request paths based on the similarity of resource paths, further includes: For any two interface request paths, determine whether the base path and the sub-paths at each level of the two interface request paths are the same. If the base path of two interface request paths is the same, and the sub-paths at each level of the two interface request paths are the same, then the two interface request paths are determined to be similar request paths.

4. The method according to any one of claims 1 to 3, characterized in that, If multiple interface request paths are similar to each other, then the multiple interface request paths are merged to obtain at least one merged request path, including: If multiple interface request paths are similar to each other, a merged request path is created. The base path of the multiple interface request paths is determined as the base path of the fusion request path; If multiple interface request paths have the same sub-path at any level, then the sub-path at that level is determined as the sub-path of the fusion request path at that level. If the sub-paths of multiple interface request paths are different at any level, then the preset general sub-path is determined as the sub-path of the fusion request path at that level. The fusion request path is obtained based on the base path and the sub-paths at each level of the fusion request path.

5. The method according to claim 4, characterized in that, The step of storing the fusion request path in the database in the form of a linked list includes: For any of the fusion request paths, a header pointer and a first meta node are created, and the base path of the fusion request path is stored using the first meta node, with the header pointer pointing to the first meta node; The following steps are executed repeatedly until all levels of sub-paths of the fusion request path have been stored: create a node and use the node to store a level of sub-paths of the fusion request path; set the node as a child node of the previous node according to the level of the sub-path.

6. An interface fusion device based on a linked list, characterized in that, The device includes: The request path acquisition module is used to acquire the interface monitoring list of the system to be monitored, wherein the interface monitoring list records multiple interface request paths of the system to be monitored. The request path fusion module is used to merge multiple interface request paths with the same function according to the preset interface request path merging rules, so as to obtain at least one merged request path. The request path storage module is used to store the fusion request path in the database in the form of a linked list; Specifically, the request path fusion module is used to extract the resource path and resource name of each interface request path; for any two interface request paths, it determines whether the base paths of the two interface request paths are the same; if the base paths of the two interface request paths are the same, it determines whether the sub-paths of the two interface request paths at each level are the same; if the sub-paths of the two interface request paths at any level are different, it calculates the similarity of the sub-paths of the two interface request paths at that level; if the similarity of the sub-paths of the two interface request paths at that level is greater than a preset similarity threshold, and the sub-paths at all levels before that level are the same and / or the similarity of the sub-paths at all levels before that level is greater than the similarity threshold, then the two interface request paths are determined to be similar request paths; if there are multiple interface request paths that are similar to each other, the multiple interface request paths are fused to obtain at least one fused request path.

7. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5.

8. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5.

Images