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

Abstract

The present application relates to the technical field of security monitoring, and discloses a linked list-based interface fusion method and apparatus, a storage medium, and a computer device. The method comprises: acquiring an interface monitoring list of a system to be monitored, wherein a plurality of interface request paths of said system are recorded in the interface monitoring list; on the basis of a preset interface request path merging rule, performing fusion processing on the plurality of interface request paths having the same function to obtain at least one fusion request path; and storing the fusion request path in a database in the form of a linked list. According to the method, the space occupied by the interface request paths can be effectively reduced, and the space utilization rate of the database is increased, thereby improving the statistics and analysis efficiency of the interface request paths.

Description

Interface fusion method, device, storage medium and computer equipment based on linked list

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on September 22, 2023, with application number 202311235938.7 and application name “Interface fusion method, device, storage medium and computer equipment based on linked list”, the entire contents of which are incorporated by reference into the application. Technical Field

[0002] The present application relates to the field of security monitoring technology, and in particular to a linked list-based interface fusion method, device, storage medium, and computer equipment. Background Art

[0003] 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 issues. API call monitoring can help promptly identify and resolve performance bottlenecks, errors, and anomalies, thereby improving system reliability and stability.

[0004] When monitoring a system's interfaces, a large number of interface request paths with overlapping functions may be detected. For example, if a client requests to obtain a user ID from multiple users, multiple interface request paths may be detected. In the prior art, when monitoring a system's interfaces, all monitored interface request paths are stored in a database to facilitate subsequent statistical analysis. However, a large number of interface request paths consumes considerable database space, hindering subsequent statistical analysis.

[0005] Application Contents

[0006] In view of this, the present application provides an interface fusion method, device, storage medium and computer equipment based on a linked list, the main purpose of which 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.

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

[0008] Acquire 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;

[0009] According to a preset interface request path merging rule, multiple interface request paths with the same function are merged to obtain at least one fused request path;

[0010] The fusion request path is stored in the database in the form of a linked list.

[0011] According to a second aspect of the present application, a linked list-based interface fusion device is provided, the device comprising:

[0012] A request path acquisition module is used to obtain 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;

[0013] A request path fusion module is used to fuse multiple interface request paths with the same function according to a preset interface request path merging rule to obtain at least one fused request path;

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

[0015] According to a third aspect of the present application, a storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the above-mentioned interface fusion method based on the linked list is implemented.

[0016] According to a fourth aspect of the present application, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned linked list-based interface fusion method when executing the program.

[0017] The present application provides a linked list-based interface fusion method, device, storage medium, and computer equipment. The method first obtains multiple interface request paths of the system to be monitored, then fuses multiple interface request paths with the same function according to a preset interface request path merging rule to obtain at least one fused request path, and finally stores the fused request path in the form of a linked list in a database. The above method can effectively reduce the space occupied by the interface request path by fusing multiple interface request paths with the same function to obtain at least one fused request path, and storing the fused request path in the form of a linked list in the database, thereby improving the space utilization of the database and thus improving the statistical and analytical efficiency of the interface request path.

[0018] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0020] FIG1 is a schematic diagram showing a flow chart of an interface fusion method based on a linked list provided in an embodiment of the present application;

[0021] FIG2 shows a schematic structural diagram of an interface fusion device based on a linked list provided in an embodiment of the present application. DETAILED DESCRIPTION

[0022] The present application will be described in detail below with reference to the accompanying drawings and in combination with embodiments. It should be noted that, unless there is a conflict, the embodiments and features in the embodiments of the present application can be combined with each other.

[0023] In one embodiment, as shown in FIG1 , a linked list-based interface fusion method is provided. The method is described by taking the application of the method to a computer device such as a server as an example, and includes the following steps:

[0024] 101. Obtain an interface monitoring list of a system to be monitored, wherein the interface monitoring list records multiple interface request paths of the system to be monitored.

[0025] The interface request path (hereinafter referred to as the request path) refers to the path that the client uses to request access to the server. The purpose of the client submitting the request path is to access the specified resource on the server. Therefore, the request path usually consists of two parts: the resource path and the resource name. For the request path, the dividing line between the resource path and the resource name is the last slash in the request path. That is, the part before the slash is called the resource path, and the part after the slash is called the resource name. For example:

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

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

[0028] The resource name is: some.do

[0029] Furthermore, based on whether the request path can uniquely locate a resource, the request path can be divided into two categories: absolute path and relative path. Among them, the absolute path refers to the path that can uniquely locate a resource. In Web (World Wide) applications, generally, the path that begins with a request protocol is an absolute path. The absolute path is expressed in the form of a URL (Uniform Resource Locator). The relative path refers to a path that cannot uniquely locate a resource by relying solely on this path. However, if it is combined with a reference path, it can be converted into an absolute path that can locate a resource. Such a path is called a relative path. In Web applications, generally, the path that does not begin with a request protocol is a relative path. The relative path is expressed in the form of a URI (Uniform Resource Identifier). In this embodiment, the interface request path can be an absolute path or a relative path, and this embodiment does not make specific restrictions.

[0030] Specifically, a system to be monitored refers to a system that authorizes external devices to monitor its interface calls. For example, the system to be monitored can 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 application program interface exposed to the outside) of each interface of each system to be monitored, the request paths of all interfaces under the monitoring system can be monitored. Then, all monitored interface request paths can be stored in an interface monitoring list to facilitate further processing of the interface request paths in the interface monitoring list.

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

[0032] Among them, multiple interface request paths with the same function refer to the data request functions implemented by the multiple interface request paths being the same, wherein the requested data may be the same or different. For example, two interface request paths are both used to request a user ID, 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. For another example, two interface request paths are 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 are the same, the two interface request paths do not have the same function.

[0033] Specifically, for any two interface request paths, if the two interface request paths have the same function, the resource paths of the two interface request paths should be the same or very similar. By utilizing this feature, an interface request path merging rule can be set, and through the interface request path merging rule, the similarity judgment of the resource paths at each level of each two interface request paths in the interface monitoring list can be performed step by step, thereby obtaining the similarity judgment result of each two interface request paths in the interface monitoring list. Furthermore, through the similarity judgment result of each two interface request paths in the interface monitoring list, it can be determined whether there are multiple interface similar paths whose similarity to each other reaches the interface merging condition in the preset interface request path merging rule. If the condition is met, the multiple interface request paths can be fused to obtain at least one fused request path.

[0034] In this embodiment, when fusing multiple interface request paths, it is possible not to fuse the protocols and domain names in the resource paths, but only to fuse the resource paths and resource names other than the protocols and domain names in the interface request paths. The reason is that the protocols and domain names of the system to be monitored are usually fixed, and fusing the protocols and domain names is not very meaningful, and will occupy the storage space of the database. In addition, fusing resource paths refers to merging the paths of multiple interface request paths at the same level into one path; fusing resource names refers to merging the resource names of multiple interface request paths into one resource name. This embodiment can reduce the space occupied by interface request paths in the database by fusing multiple interface request paths.

[0035] 103. Store the fusion request path in the database in the form of a linked list.

[0036] A linked list, also known as a chain storage structure or singly linked list, is a linear storage structure. It doesn't restrict the physical storage state of data. Data elements stored in a linked list have random physical locations. Therefore, using a linked list to store data can improve database space utilization.

[0037] Specifically, the fused request path typically has multiple levels. Taking the request path in step 101 as an example, the request path includes a resource path and a resource name. Based on this, the fused request path after fusion processing also includes at least two levels: the resource path and the resource name. In addition, for some fused request paths, their resource paths typically have multiple levels, with each level separated by a slash. Accordingly, the linear storage structure of a linked list can be used to store data with multiple levels, wherein each node of the linked list can be used to store a resource path or resource name of a level in the fused request path, and each node in the linked list can point to the next node via an address pointer, thereby forming a hierarchical structure of the fused request path. This embodiment uses a linked list storage structure to store the fused request path, which can completely preserve the hierarchical structure of the fused request path. Moreover, after the fusion process, the number of nodes occupied by the fused request path is greatly reduced compared to before the fusion process. Therefore, storing the fused request path through a linked list structure can effectively reduce the space occupancy rate of the database. In addition, the storage structure of the linked list itself also determines that the space utilization rate of the fused request path is relatively high.

[0038] The linked list-based interface fusion method provided in this embodiment first obtains multiple interface request paths of the system to be monitored, then fuses multiple interface request paths with the same function according to a preset interface request path merging rule to obtain at least one fused request path, and finally stores the fused request path in the database in the form of a linked list. By fusing multiple interface request paths with the same function to obtain at least one fused request path, and storing the fused request path in the database in the form of a linked list, the above method can effectively reduce the space occupied by the interface request path, improve the space utilization of the database, and thus improve the statistical and analytical efficiency of the interface request path.

[0039] 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, the multiple interface request paths are fused to obtain at least one fused request path.

[0040] For example, when monitoring the endpoints of all interfaces under a certain system, the following interface request paths were detected, namely: 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 similarity judgment on the resource paths of each two interface request paths, it can be found that the resource paths of the above six interface request paths are the same, all of which are / 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, it can still be determined that the above six interface request paths are similar request paths to each other. Therefore, the above six interface request paths can be fused to obtain a fused request path of / api / user / get / {id}.

[0041] The above embodiment calculates the similarity of the resource paths of any two interface request paths among multiple interface request paths, and based on the similarity of the resource paths of each pair of interface request paths, determines whether multiple interface request paths are mutually similar request paths, and then fuses the multiple interface request paths that are mutually similar request paths to obtain at least one fused request path. The above 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.

[0042] In one embodiment, the method for determining whether any two interface request paths are similar request paths in the above embodiment can be implemented by the following steps: for any two interface request paths, determine whether the base paths of the two interface request paths and the sub-paths of each level are the same; if the base paths of the two interface request paths are the same, and the sub-paths of each level of the two interface request paths are the same, then it is determined that the two interface request paths are similar request paths.

[0043] Among them, the base path refers to the path with the highest level in the resource path except for the protocol and domain name. After the base path, the sub-paths of each level are divided in turn by slashes, and the level of the sub-path after each slash is one level lower than the level of the sub-path before the slash. For example, the base path of the interface request path: http: / / hostname / api / user / get / 1 is api, the sub-path of the next level is user, and the sub-path of the next level is get, where hostname is the domain name and 1 is the resource name. In this embodiment, judging whether the base paths of two interface request paths are the same refers to judging whether the string corresponding to the base path of one interface request path is exactly the same as the string corresponding to the base path of another interface request path. In addition, judging whether the sub-paths of each level of two interface request paths are the same refers to judging whether the string corresponding to the sub-path of one level of one interface request path is exactly the same as the string corresponding to the sub-path of the same level of another interface request path.

[0044] For example, taking the following two interface request paths as an example: http: / / hostname / api / user / get / 1 and http: / / hostname / api / user / get / 2, when determining whether these two interface request paths are similar request paths, you can first determine whether the base paths of the two interface request paths are the same, and then determine in turn whether the sub-paths of the two interface request paths at each level are the same. Through judgment, it can be found that the base paths of the two interface request paths are the same, and the sub-paths of each level of the two interface request paths are also the same. Therefore, it can be determined that the above two interface request paths are similar request paths.

[0045] The above embodiment determines that two interface request paths are similar request paths by judging whether the basic paths of any two interface request paths and the sub-paths of each level are the same. It can accurately judge whether any two interface request paths are interface request paths with the same functions, thereby improving the accuracy of interface request path merging.

[0046] 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 by 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 one by one whether the subpaths of the two interface request paths at each level are the same. If the subpaths of the two interface request paths at any level are different, then calculate the similarity of the subpaths of the two interface request paths at that level. If the similarity of the subpaths of the two interface request paths at that level is greater than a preset similarity threshold, and the subpaths of each level before that level are the same and / or the similarity of the subpaths of each level before the level is greater than the similarity threshold, then determine that the two interface request paths are similar request paths.

[0047] In the above embodiment, calculating the similarity of the sub-paths of two interface request paths at any level 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 speaking, when the sub-paths of two interface request paths at a certain level are very similar, 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. This feature can be used to determine whether the two interface request paths are similar request paths.

[0048] For example, taking the following two interface request paths as examples: http: / / hostname / api / user / get / aa1992bb10aa12 / aa1 and http: / / hostname / api / user / get / aa1992bb10aa21 / aa2, when judging whether these two interface request paths are similar request paths, we can first judge whether the base paths of the two interface request paths are the same. After judging that the base paths are the same, we can then judge in turn whether the sub-paths of the two interface request paths at each level are the same. Through judgment, it is found that the base paths of the two interface request paths are the same, and the similarity of the sub-paths of the two interface request paths at the third level is greater than the preset similarity threshold, and the sub-paths of the two interface request paths at the first level and the sub-paths at the second level are the same, so it can be determined that the two interface request paths are similar request paths.

[0049] The above embodiment calculates the similarity of the sub-paths of two interface request paths at any level, and determines whether the two interface request paths are similar request paths based on the similarity of the two sub-paths. This can avoid the problem of multiple interface request paths with the same functions being missed from being merged, thereby improving the accuracy of interface request path fusion.

[0050] 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 by the following steps: first, performing word segmentation processing on the two sub-paths at the same level of the two interface request paths, and then calculating the word frequency and arrangement order of each word segmentation result of the two sub-paths, and then determining 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 weighting the word frequency vectors of the two sub-paths based on the arrangement order of each word segmentation result of the two sub-paths, and finally calculating the similarity of the word frequency vectors of the two sub-paths through a preset similarity calculation formula to obtain the similarity of the sub-paths of the two interface request paths at the level.

[0051] For example, the two sub-paths of two interface request paths at the same level are [aa1992bb10aa12] and [aa1992bb10aa21]. By performing word segmentation on the two sub-paths, the word segmentation results of the two sub-paths are:

[0052]

aa1992bb10aa12

[0053]

aa1992bb10aa21

[0054] Then, by calculating the word frequency of each word segmentation result of the two subpaths and determining the word frequency vectors of the two subpaths based on the word frequency of each word segmentation result of the two subpaths, the following results can be obtained:

[0055]

aa1992bb10aa12

[0056]

aa1992bb10aa21

[0057] Furthermore, the word frequency vectors of the two subpaths can be weighted based on the order of their respective word segmentation results. For example, the word segmentation result aa can be weighted to have a weight of 3 or 4, etc. Finally, using a preset similarity calculation formula, such as the cosine similarity calculation formula, the similarity of the word frequency vectors of the two subpaths can be calculated, resulting in a similarity of 87.5% between the subpaths of the two interface request paths at this level. Thus, it can be determined that the similarity between the two subpaths of the two interface request paths at this level is 87.5%, and furthermore, it can be determined that the similarity between the two subpaths of the two interface request paths at this level is greater than a preset similarity threshold of 85%.

[0058] The above embodiment obtains the word frequency vectors of the two sub-paths at the same level of the two interface request paths by performing word segmentation and weighting processing on the two sub-paths, and performs similarity calculation on the word frequency vectors of the two sub-paths to obtain the similarity of the sub-paths of the two interface request paths at the same level, which can improve the accuracy of sub-path similarity judgment, thereby improving the accuracy of interface request path fusion.

[0059] In one embodiment, the method for fusing multiple interface request paths into a fused request path in the above embodiment can be implemented by the following steps: if there are multiple interface request paths that are similar to each other, a fused request path is created, and then the base path of the multiple interface request paths is determined as the base path of the fused request path. Furthermore, if the sub-paths of the multiple interface request paths at any level are the same, the sub-path of the level is determined as the sub-path of the fused request path at the level; if the sub-paths of the multiple interface request paths at any level are different, the preset universal sub-path is determined as the sub-path of the fused request path at the level. Finally, the fused request path is obtained based on the base path of the fused request path and the sub-paths of each level.

[0060] For example, taking the following three interface request paths as examples: http: / / hostname / api / user / get / aa1992bb10aa12 / aa1, http: / / hostname / api / user / get / aa1992bb10aa21 / aa2, and http: / / hostname / api / user / get / aa1992bb10aa21 / aa3, assuming that the three interface request paths are similar, a fused request path can be created. The fused request path has the base path of api, the next sub-path is user, the next sub-path is get, and the next sub-path is the preset common sub-path {param}. Finally, the resource name of the fused request path can be the resource name of each interface request path: aa1, aa2, and aa3, or the preset universal resource name: {aaid}. The final fused request path is / api / user / get / {param} / {aaid}, or / api / user / get / {param} / aa1, / api / user / get / {param} / aa2, and / api / user / get / {param} / aa3.

[0061] In the above embodiment, by fusing multiple interface request paths to obtain at least one fused request path, the space occupied by subsequently storing the interface request paths in the database can be reduced, thereby improving the efficiency of interface request path analysis and statistics.

[0062] In one embodiment, step 103 can be implemented by the following method: for any fused request path, first create a head pointer and a header node, and use the header node to store the base path of the fused request path, where the head pointer points to the header node. Then, loop through the following steps until all subpaths at all levels of the fused request path are stored: create a node, use the node to store the subpaths of one level of the fused request path, and then, based on the level of the subpath, set the node as a child of the previous node.

[0063] For example, take the fusion request path described in the previous embodiment as an example: / api / user / get / {param} / {aaid}. For this fusion method, the fusion request path can be stored in the following way: the basic path api is stored in the first element node, and then user, get, {param}, {aaid} are stored in each newly created node in turn, and a hierarchical relationship is established between each node and the previous node. Among them, 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}. Through the above method, a fusion request path can be stored in the database.

[0064] Furthermore, let's take 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 in the following way: the basic path api is stored in the first element node, and then user, get, {param}, aa1, aa2, aa3 are stored in each newly created node in sequence, and a hierarchical relationship is established between each node and the previous node. Among them, 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 right child node of the node storing {param}. Through the above method, the storage of a fusion request path in the database can also be realized.

[0065] In the above embodiment, after the multiple interface request paths are fused, they can be stored in the database in the form of a linked list, thereby reducing the number of nodes in the linked list and the space occupied by the interface request path storage. 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.

[0066] In one embodiment, multiple interface request paths can also be manually fused. Specifically, if a technician determines that multiple interface request paths have the same function, the computer device can, in response to a path fusion operation, sequentially fuse the resource paths and resource names at each level of the multiple interface request paths to obtain at least one fused request path. The fused request paths are then stored in the database in the form of a linked list, thereby reducing database space usage and improving database space utilization.

[0067] Furthermore, as a specific implementation of the method shown in FIG1 , this embodiment provides an interface fusion device based on a linked list, as shown in FIG2 , which includes: a request path acquisition module 31 , a request path fusion module 32 and a request path storage module 33 .

[0068] The request path acquisition module 31 is configured to acquire 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;

[0069] The request path fusion module 32 may be configured to fuse multiple interface request paths having the same function according to a preset interface request path merging rule to obtain at least one fused request path;

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

[0071] In a specific application scenario, 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, the multiple interface request paths are fused to obtain at least one fused request path.

[0072] In a specific application scenario, the request path fusion module 32 can be specifically used to determine whether the basic paths of any two interface request paths are the same; if the basic paths of the two interface request paths are the same, then determine one by one 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, then calculate the similarity of the sub-paths of the two interface request paths at the level; if the similarity of the sub-paths of the two interface request paths at the level is greater than a preset similarity threshold, and the sub-paths of each level before the level are the same and / or the similarity of the sub-paths of each level before the level is greater than the similarity threshold, then determine that the two interface request paths are similar request paths.

[0073] In a specific application scenario, the request path fusion module 32 can be specifically used to perform word segmentation processing on the two sub-paths of the two interface request paths at the same level; calculate the word frequency and arrangement 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 arrangement order of each word segmentation result of the two sub-paths; calculate the similarity of the word frequency vectors of the two sub-paths through a preset similarity calculation formula to obtain the similarity of the sub-paths of the two interface request paths at the level.

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

[0075] In a specific application scenario, the request path fusion module 32 can be specifically used to create a fused request path if there are multiple interface request paths that 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 at any level are the same, determine the sub-path of the level as the sub-path of the fused request path at the level; if the sub-paths of the multiple interface request paths at any level are different, determine the preset common sub-path as the sub-path of the fused request path at the level; and obtain the fused request path based on the base path of the fused request path and the sub-paths of each level.

[0076] In a specific application scenario, the request path storage module 33 can be used to create a head pointer and a first element node for any of the fused request paths, and use the first element node to store the basic path of the fused request path, and the head pointer points to the first element node; loop the following steps until all levels of the sub-paths of the fused request path are stored: create a node, and use the node to store a level of sub-path of the fused request path, and set the node as a child node of the previous node according to the level of the sub-path.

[0077] It should be noted that, for other corresponding descriptions of the functional units involved in the interface fusion device based on a linked list provided in this embodiment, reference can be made to the corresponding descriptions of the above embodiments, which will not be repeated here.

[0078] Based on the methods shown in the above embodiments, this embodiment also provides a storage medium on which a computer program is stored. When the program is executed by a processor, the interface fusion method based on the linked list as described in the above embodiments is implemented.

[0079] Based on this understanding, the technical solution of the present 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 (which can be a CD-ROM, USB flash drive, mobile hard disk, etc.), including a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods described in each implementation scenario of the present application.

[0080] Based on the above method as shown in Figure 1 and the embodiment of the interface fusion device based on the linked list as shown in Figure 2, in order to achieve the above purpose, this embodiment also provides a computer device based on the linked list interface fusion, which can be specifically a personal computer, a server, a smart phone, a tablet computer, a smart watch, or other network devices, 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 computer programs to implement the methods described in the above embodiments.

[0081] Optionally, the computer device may further include an internal memory, a communication interface, a network interface, a camera, a radio frequency (RF) circuit, a sensor, an audio circuit, a Wi-Fi module, a display, an input device such as a keyboard, etc. Optionally, the communication interface may further include a USB interface, a card reader interface, etc. The network interface may optionally include a standard wired interface, a wireless interface (such as a Wi-Fi interface), etc.

[0082] Those skilled in the art will understand that the computer device structure for identifying an operation action provided in this embodiment does not constitute a limitation on the computer device, and may include more or fewer components, or a combination of certain components, or different component arrangements.

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

[0084] Through the description of the above implementation methods, those skilled in the art can clearly understand that the present application can be implemented by means of software plus the necessary general hardware platform, or by hardware. By applying the technical solution of the present application, multiple interface request paths of the system to be monitored are first obtained, and then, according to the preset interface request path merging rules, multiple interface request paths with the same function are fused to obtain at least one fused request path, and finally, the fused 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 the interface request path, improve the space utilization of the database, and improve the statistical and analysis efficiency of the interface request path.

[0085] Those skilled in the art will understand that the accompanying drawings are only schematic diagrams of a preferred implementation scenario, and the modules or processes in the accompanying drawings are not necessarily required to implement the present application. Those skilled in the art will understand that the modules in the devices in the implementation scenario can be distributed in the devices of the implementation scenario according to the implementation scenario description, or can be changed accordingly and located in one or more devices different from the implementation scenario. The modules of the above-mentioned implementation scenario can be combined into one module, or can be further split into multiple sub-modules.

[0086] The serial numbers of the above application are for descriptive purposes only and do not represent the advantages or disadvantages of the implementation scenarios. The above disclosure only discloses several specific implementation scenarios of the present application, but the present application is not limited thereto. Any changes that can be conceived by those skilled in the art should fall within the scope of protection of the present application.

Claims

1. A linked list-based interface fusion method, wherein: The method comprises: 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; According to a preset interface request path merging rule, 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 in the form of a linked list.

2. The method according to claim 1, wherein: The step of fusing multiple interface request paths having the same function according to a preset interface request path merging rule to obtain at least one fused request path includes: Extracting the resource path and resource name of each interface request path; Calculating the similarity of the resource paths of any two of the interface request paths, and determining whether any two of the 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, the multiple interface request paths are fused to obtain at least one fused request path.

3. The method according to claim 2, wherein: The calculating the similarity of the resource paths of any two of the interface request paths, and determining whether any two of the interface request paths are similar request paths according to the similarity of the resource paths, comprises: For any two of the interface request paths, determining 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, determining whether the sub-paths of the two interface request paths at each level are the same one by one; If the sub-paths of the two interface request paths at any level are different, then the similarity of the sub-paths of the two interface request paths at the level is calculated; If the similarity of the sub-paths of the two interface request paths at the level is greater than a preset similarity threshold, and the sub-paths of each level before the level are the same and / or the similarity of the sub-paths of each level before the level is greater than the similarity threshold, then the two interface request paths are determined to be similar request paths.

4. The method according to claim 3, wherein: The calculating the similarity of the sub-paths of the two interface request paths at the level includes: Performing word segmentation processing on two sub-paths of the two interface request paths at the same level; Calculate the word frequency and ranking of each word segmentation result of the two subpaths; Determine the word frequency vectors of the two sub-paths according to the word frequencies of each word segmentation result of the two sub-paths, and perform weighted processing on the word frequency vectors of the two sub-paths according to the arrangement order of each word segmentation result of the two sub-paths; The similarity of the word frequency vectors of the two sub-paths is calculated by using a preset similarity calculation formula to obtain the similarity of the sub-paths of the two interface request paths at the level.

5. The method according to claim 2, wherein: The calculating the similarity of the resource paths of any two of the interface request paths, and determining whether any two of the interface request paths are similar request paths according to the similarity of the resource paths, further includes: For any two of the interface request paths, determine whether the base paths and sub-paths at each level of the two interface request paths are the same; If the base paths of the two interface request paths are the same, and the sub-paths of each level of the two interface request paths are the same, then the two interface request paths are determined to be similar request paths.

6. The method according to any one of claims 2 to 5, wherein: 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, including: If there are multiple interface request paths that are similar to each other, create a fused request path; Determine the base path of the plurality of interface request paths as the base path of the fused request path; If the sub-paths of the plurality of interface request paths at any level are the same, the sub-path of the level is determined as the sub-path of the fused request path at the level; If the sub-paths of the plurality of interface request paths at any level are different, determining the preset common sub-path as the sub-path of the fused request path at the level; The fused request path is obtained according to the base path of the fused request path and the sub-paths of each level.

7. The method according to claim 6, wherein: The step of storing the fusion request path in a database in the form of a linked list includes: For any of the fusion request paths, create a head pointer and a header node, and use the header node to store the basic path of the fusion request path, the head pointer points to the header node; The following steps are executed in a loop until all sub-paths of all levels of the fused request path are stored: a node is created, and the sub-path of one level of the fused request path is stored using the node, and the node is set as a child node of the previous node according to the level of the sub-path.

8. An interface fusion device based on a linked list, wherein: The device comprises: A request path acquisition module, used to acquire 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; A request path fusion module, used to fuse multiple interface request paths with the same function according to a preset interface request path merging rule to obtain at least one fused request path; The request path storage module is used to store the fused request path in the form of a linked list in the data In the library.

9. A storage medium having a computer program stored thereon, wherein: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images